Connect Microsoft Entra
Advania ALT federates sign-in to your Microsoft Entra ID directory. You register an app in your own Entra directory and share the credentials — you keep control of who can sign in, group membership, admin consent, and secret rotation.
This is a one-time setup, done before onboarding. Expect ~30 minutes with an Entra admin available.
Prerequisites
- Global Administrator or Application Administrator on the Entra directory that will hold the app registration
- Two placeholder values from Advania:
{keycloak-host}and{org-idp-alias}— used in the Redirect URI
1. Create the app registration
Azure Portal → Microsoft Entra ID → App registrations → New registration.
- Name:
advania-alt-platform-idp(or your preferred name) - Supported account types: Single tenant (this directory only)
2. Configure redirect URIs
App registration → Authentication → Add a platform → Web.
| Type | Value |
|---|---|
| Redirect URI | https://{keycloak-host}/realms/yggdrasil/broker/{org-idp-alias}/endpoint |
| Front-channel logout URL | https://{keycloak-host}/realms/yggdrasil/broker/{org-idp-alias}/endpoint/logout-response |
Substitute the two placeholders with the values Advania sent you.
3. Emit group claims in tokens
App registration → Manifest → set:
"groupMembershipClaims": "SecurityGroup"
This includes your security-group object IDs in the groups claim of issued tokens — this is how Advania ALT learns who is an Admin vs Developer.
Important: accessTokenAcceptedVersion must be 1 (or null, which defaults to 1). If it's set to 2, the groups claim is silently dropped.
4. API permissions
App registration → API permissions → Add a permission → Microsoft Graph → Delegated:
openidemailprofileUser.Read
Then Grant admin consent for <your-directory>. Without this, users see a permission error on first sign-in.
5. Create a client secret
App registration → Certificates & secrets → New client secret. Copy the secret immediately — the value is shown only once.
When you rotate the client secret later, give Advania ≥ 24 hours' notice so we can roll the platform-side identity-provider configuration in a maintenance window.
6. Choose a role-assignment model
Pick whichever fits your existing Entra practices. Both can coexist on the same app registration.
Option A — Security groups (default)
Microsoft Entra ID → Groups → New group:
| Group name | Type | Maps to platform role |
|---|---|---|
ALT-Admins | Security | admin |
ALT-Devs | Security | developer |
Add users to each group and record each group's Object ID (OID) — you'll share it with Advania.
If a user is in 200+ security groups, Entra replaces the groups claim with an overage indicator that requires a Graph API call to resolve. Keep users under 200 groups, or filter the claim to only the two ALT-* groups via optionalClaims in the manifest.
Option B — App Roles
Define roles directly on the app registration instead of using security groups.
-
App registration → App roles → Create app role:
Value Display name adminAdmin developerDeveloper -
Microsoft Entra ID → Enterprise applications → your app → Users and groups → assign users to the desired role.
No changes are needed on the Advania ALT side.
7. Hand off to Advania
Send the following through a secure channel:
| Item | When required |
|---|---|
| Entra Tenant ID | Always |
| Client ID | Always |
| Client secret | Always |
ALT-Admins group OID | Option A only |
ALT-Devs group OID | Option A only |
Desired account name & alias (e.g. Acme Corp / acme-corp) | Always |
| Email domain | Always |
Role assignment mode (groups, app roles, or both) | Always |
Your Advania Solutions Architect drives the rest.