Single sign On (SSO) Starter Guide with Azure Active Directory
1. Description
This is a step-by-step guide to configure the Single Sign On functionality with Azure Active Directory.
2. Prerequisites
In order to set up SSO for an Alteia-based system with an Azure Active Directory acting as an Identity Provider (IDP) for users you need:
- A Domain Manager role on the Alteia-based domain
- Administration rights on your Azure Active Directory
3. Workflow
3.1 On the Aether side: Redirect URI
As domain manager, you have access to the Identity Provider (SSO) menu in the Administration module.
Open an identity provider and note its “Redirect URI” (the other fields will have to be configured at the end of the procedure)
3.2 Create an App registration in the Azure Active Directory
- Select a friendly user-facing name
- Enter the “Redirect URI” as:
- “Web”
- URI endpoint of the Alteia based system usually in the form of: https://id.{system-name}/auth/realms/{domain-name}/broker/{ali as}/endpoint
Note:
- Friendly user-facing name is for user consent (depending on IDP configuration)
- The “Redirect URI” on Azure AD can be set later
3.3 Client secret configuration
Go to the “Certificates & Secrets” menu:
- Create a new secret
- Copy and note the “Value” of the secret (Not its ID)
3.4 Client ID configuration
Go to the “Overview” option:
- Copy and note the “Client ID”
- Check the client credentials and redirect URIs from the previous steps configured
3.5 OAuth endpoints configuration
Again in the “Overview”menu, select the “Endpoint” tab:
- Copy and note the OAuth 2.0 authorization and token endpoints (v2)
3.6 Scope permissions configuration
Go to the “API permissions” menu:
- Ensure support for the OpenID claims “openid profile email”, by adding the relevant permissions if needed.
The “email” scope on Azure AD also requires an optional claim in “Token configuration” (Ideally also check that the first name, last nameand user name are enabled)
During the last 5 steps you have configured AND noted:
- Client ID
- Client Secret
- OAuth 2.0 authorization endpoint
- OAuth 2.0 token endpoint
3.7 Aether-based system setup
Go back to the Identity Provider on the Aether-based system and:
- Fill in the relevant fields
- Enable the IDP
- Save
Extra configuration - Mail pattern rules
- The mail pattern rules define how the SSO policy applies to your users
- Based on mail patterns on regular expressions
- “Inclusion rule” (*): who can use this IDP
- “Exclusion rule” (*): whom to exclude from the previous rule
- “Credentials exception” (*): who can access with (platform) email/password credentials - We recommend at least one domain administrator to have password credentials allowed
Example:
Inclusion: “*@alteia.com” = everyone with and Alteia email
Exclusion: “*-ext@alteia.com” = except external resources whose mail name ends with - ext
Credential: “john.doe@alteia.com” = John Doe can bypass the SSO and use platform credentials for login
(*) these rules are case-insensitive. This means that they will be treated the same, regardless of the case.
