Single Sign-On (SSO) Requirements
1. Description
This article will describe the basic information on the Single Sign On (SSO) authentication method and the requirements to deploy it on your domain.
The single sign-on (SSO) authentication method allows your Aether's users to securely login by using your own enterprise identity provider.
Aether users will be able to use their enterprise credentials.
2. How does it work?
In Aether, the SSO is configured per domain, and there is no “role mapping” done with the enterprise identity provider (IDP), which means that users on the enterprise IDP do not have a default access.
Users with “Manager” rights still grant access to other users, by mail invitation, and define which roles, organizations, companies, and projects are available to each user.
Aether delegates the authentication to the enterprise identity provider (IDP), so there is no pre-authenticated login page.
If SSO is activated on the domain, the users won't be able to access the Aether desktop application.
3. Supported IDP protocols & requirements
The enterprise identity provider (IDP) must support:
- Open ID Connect (OIDC) protocol.
- Claims for first name, last name, and email - Corresponding to the “openID profile email” basic OIDP scopes.
Examples of compliant IDPs:
- Google Workspace Enterprise (formerly Gmail for Business)
- Microsoft Azure Active Directory
Aether currently doesn’t support “Back-channel logout”
4. Configuring the solution with Open ID Connect (OIDC)
There are two required steps to configure the SSO with Open ID Connect (OIDC) protocol:
- On the Alteia-based system side:
- Instances with the additional SSO modules/components deployed and configured
- “Redirect URI” or response URL endpoint configured on the SSO-enables domains (To be configured on the enterprise IDP side)
- From the enterprise IDP side (as output, to be configured on the Alteia-based system side):
- Client’s ID
- Client’s secret*
- OAuth2/OIDC endpoints**
*For starter configuration and interoperability checks:
- We assume the simple authentication method “Post with Client’s ID and Client’s secret”.
- Several more advanced authentication methods exist and may be studied after successful interoperability (e.g. JWT, certificates, &c).
- Secrets have an expiration date - please start with a decent initial setup (e.g. annual) - Secret renewal is not discussed here.
** For interoperability checks:
- 2 endpoints are required: the “Open ID Connect“ authorization endpoint & “token” endpoint.
- Scope “OpenID profile email” must be enabled on both types of tokens (access tokens and ID tokens) - to minimally retrieve the following user details: first name, last name, and email.
- Other endpoints and scopes exist and could be considered for more advanced setups.
