FoxIDs is an open source identity service supporting login, OAuth 2.0, OpenID Connect 1.0, SAML 2.0 and convention between the standards.
FoxIDs can at the same time work as both an authentication platform and a security broker converting between standards.
STATUS: I'm currently working on the documentation and the first FoxIDs beta version.
FoxIDs consist of two services:
Deployment or as a service:
FoxIDs is .NET 5.0 and the FoxIDs Control Client is Blazor .NET Standard 2.1.
FoxIDs is free and the open source with a GitHub repository.
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.
Please ask your question on Stack Overflow and email a link to [email protected] for me to answer.
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:
Both is exposed as websites where the domains can be customized. FoxIDs also relay on a number of backend service, please see development for details.
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 https://foxidsxxxx.com/tenant-x/track-y/down-party-z/
.
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 https://foxidsxxxx.com/tenant-x/track-y/down-party-z(up-party-v)/
.
The allowed up parties for a down-party is configured for each down-party in FoxIDs Control.
Selecting multiple up parties (future support):
https://foxidsxxxx.com/tenant-x/track-y/down-party-z(*)/
https://foxidsxxxx.com/*tenant-x*/*track-y*/*down-party-z*(up-party-v1*,up-party-v2*,up-party-v3,up-party-v4,up-party-v5)/
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.
When a track is created it is default equipped with a self-signed certificate stored in Cosmos DB, called a contained certificate. The certificate can afterword's be updated / changed and likewise the certificate container type can be changed.
There are tree different certificate container types:
Contained certificates (default)
Key Vault, renewed self-signed certificates
Key Vault, upload your one certificate (future support)