FoxIDs

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:

  • Identity service called FoxIDs which handles user login and all other security traffic.
  • Configuration client and API called FoxIDs Control. The FoxIDs Control Client is used to configure FoxIDs, or alternatively by calling the FoxIDs Control API directly.

Deployment or as a service:

  • FoxIDs is a cloud service ready to be deployed in you Azure tenant.
  • Or you can use FoxIDs as an identity as a service (IDaaS) at https://FoxIDs.com.

FoxIDs is .NET 5.0 and the FoxIDs Control Client is Blazor .NET Standard 2.1.

Free and Open Source

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.

Support

Please ask your question on Stack Overflow and email a link to [email protected] for me to answer.

How FoxIDs works

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, the identity service which handles all the security requests and user authentication
  • FoxIDs Control, the administration application and API in which FoxIDs is configured

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.

Structure

FoxIDs is divided into logical elements.

  • Tenant contain the company, organization, individual etc. security service. A tenant contains the tracks.
  • Track is a production, QA, test etc. environment. Each track contains a user repository, a unique certificate and a track contains the up parties and down parties.
  • Up-party is a upwards trust / federation or login configuration. Currently support: login (one view with both username and password) and SAML 2.0. Future support: OpenID Connect and two step login (two views separating the username and password input).
  • Down-party is a downward application configuration. Currently support: OpenID Connect (secret or PKCE), OAuth 2.0 API and SAML 2.0.

FoxIDs structure

FoxIDs support unlimited tenants. Unlimited tracks in a tenant. Unlimited users, up parties and down parties in a track.

Separation

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):

  • Select all up parties allowed for a down-party by adding a star in round brackets in the URL after the down-party name https://foxidsxxxx.com/tenant-x/track-y/down-party-z(*)/
  • Select a maximum of 5 up parties allowed for a down-party by adding the up parties as a comma separated list in round brackets in the URL after the down-party name 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.

Certificates

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)

  • Certificates is stored in Cosmos DB including private key.
  • Self-signed certificates is created by FoxIDs or you can upload your one certificates.
  • Support primary and secondary certificates, and certificate swap.
  • Not automatically renewed.
  • No cost per signing.

Key Vault, renewed self-signed certificates

  • Certificates is stored in Key Vault and the private key is not exportable.
  • Self-signed certificates is created by Key Vault.
  • Automatically renewed with 3 month validity period. Renewed 10 days before expiration and exposed as the secondary certificate. Promoted to be the primary certificate 5 days before expiration.
  • Key Vault cost per signing.

Key Vault, upload your one certificate (future support)

  • Certificates is stored in Key Vault and the private key is not exportable.
  • Not automatically renewed.
  • Key Vault cost per signing.

Content