FoxIDs is an open source identity service supporting login, OAuth 2.0, OpenID Connect 1.0, SAML 2.0 and convention between the standards.
STATUS: I'm currently working on the documentation and the first FoxIDs beta version.
FoxIDs consist of two services:
FoxIDs is a cloud service ready to be deployed in you Azure tenant. In the future, it will also be possible to use FoxIDs on https://FoxIDs.com and https://Control.FoxIDs.com for at small transaction fee.
FoxIDs is .NET Core 3.1 and the FoxIDs Control Client is Blazor .NET Standard 2.1.
FoxIDs is free and the open source GitHub repository is https://github.com/ITfoxtec/FoxIDs.
The license grant all (individuals, companies etc.) the right to use FoxIDs for free. The license restricts reselling FoxIDs e.g. as a cloud service to third parties, without a supplementary agreement.
FoxIDs is a multi-tenant system designed to be deployed in the Azure cloud. FoxIDs support being deployed as a service used by many companies, organizations etc. each with its one tenant. Or to be deployed in a company's Azure subscription where only one tenant is configured in FoxIDs holding the company's entire security service.
FoxIDs is deployed in two App Services which expose:
FoxIDs is divided into logical elements.
FoxIDs support unlimited tenants. Unlimited tracks in a tenant. Unlimited users, up parties and down parties in a track.
The structure is used to separate the different tenants, tracks and parties.
If the FoxIDs is hosted on
https://foxidsxxxx.com/ the tenants are separated in the first folder of the URL
https://foxidsxxxx.com/tenant-x/. The tracks are separated in the second folder of the URL
https://foxidsxxxx.com/tenant-x/track-y/ under each tenant.
A down party is call by adding the down party name as the third folder in the URL
A up party is call by adding the up party name insight round brackets as the third folder in the URL
https://foxidsxxxx.com/tenant-x/track-y/(up-party-v)/. If FoxIDs handles a up party sequence like e.g. user authentication the same URL notation is used thus locking the session cookie to the URL.
A client (application) starting an OAuth 2.0, OpenID Connect or SAML 2.0 login sequence would like to specify in which up party the user should authenticate. The resulting up party is specified by adding the up party name in round brackets in the URL after the down party name
The allowed up parties for a down party is configured for each down party in FoxIDs Control.
Selecting multiple up parties (future support):
A client which use client credentials as authorization grant would not specify the up party. It is likewise optional to specify the up party when calling an OpenID Connect discovery document or a SAML 2.0 metadata endpoint.