Aller au contenu principal
Version 0.5Brouillon

Single sign-on and LuxID Pro

What is single sign-on on LuxID?​

LuxID provides two distinct SSO capabilities: consumer SSO across LuxID-enabled applications, and LuxID Pro enterprise federation with a corporate IdP.

The two capabilities are:

  1. Consumer SSO - a user who is already signed in to LuxID is automatically authenticated when they visit a second LuxID-enabled application, without re-entering their credentials.
  2. LuxID Pro - Enterprise Federation - an organisation's employees use their corporate identity provider (Microsoft Entra, Okta, Ping, ADFS, or similar) to authenticate to LuxID-enabled applications. The corporate IdP is federated into LuxID, and employees see their corporate sign-in experience rather than the standard LuxID login form.

These two flavours are independent and can coexist: an organisation running LuxID Pro for its employees can simultaneously have those employees benefit from consumer SSO when they access other LuxID Partners with their corporate credentials.

Consumer SSO​

How it works​

LuxID maintains a session cookie on the login.luxid.lu domain after a user authenticates. When the same user initiates an authorisation flow to a different LuxID-enabled application, Universal Login detects the existing session and completes the flow silently - issuing new tokens without prompting the user for credentials again.

From the user's perspective: sign in once (to MyPost, for example), then navigate to RTL Play - and they are signed in immediately without seeing a login form.

From the developer's perspective: the authorisation flow completes as normal. The returned tokens reflect the session's existing assurance level. The auth_time claim reflects the original authentication time, not the time of the silent re-authentication.

Sphere boundaries​

SSO works within the boundaries of a Sphere. A Sphere is a pseudonymisation domain: applications within the same Sphere share the same sub value for a given user, enabling a seamless SSO experience. Applications in different Spheres receive different sub values for the same user.

Cross-Sphere navigation does not automatically produce SSO. Even if the user has an active LuxID session, accessing an application in a different Sphere requires a fresh consent screen (since the Sphere boundary implies a different pseudonymous identity context). The user is not prompted for credentials again, but they do see a consent screen for the new application.

Sphere assignment is configured with LuxID when an Application is created. Partners in the same organisation typically share a Sphere. Partners from different organisations are typically in different Spheres.

prompt parameter behaviour​

prompt valueEffect on consumer SSO
(absent)Session reused silently if available.
noneSession reused silently; returns error=login_required if no session.
loginForces fresh credential entry, ignoring existing session.
consentForces consent screen, even if previously consented.

Silent re-authentication flow​

Checking session freshness​

If your application requires a recent authentication - for example, before allowing a password change - check the auth_time claim against the current time. If the session is stale (for example, more than 15 minutes old), use prompt=login to require fresh credentials:

function requireFreshSession(idTokenClaims, maxAgeSeconds = 900) {
  const sessionAge = Date.now() / 1000 - idTokenClaims.auth_time;
  if (sessionAge > maxAgeSeconds) {
    // Redirect to LuxID with prompt=login
    throw new StaleSessionError('Session too old for this operation');
  }
}

Alternatively, pass max_age=<seconds> on the authorisation request and LuxID will enforce freshness server-side, prompting for re-authentication if the session exceeds the specified age.

LuxID Pro - enterprise federation​

What is LuxID Pro?​

LuxID Pro is an enterprise federation service that allows organisations to connect their corporate identity provider to LuxID. Once a federation is configured, employees of that organisation authenticate using their corporate credentials (username, password, corporate MFA) rather than creating a separate LuxID Account.

The result: employees of POST Luxembourg (for example) can sign in to RTL Play using their @post.lu corporate credentials. RTL Play receives a standard LuxID token. The user's corporate identity is translated into LuxID's token format transparently.

What your employees will see

The employee-facing side of a LuxID Pro account (what changes for the person signing in, and which settings their organisation manages) is documented in the user help: Manage your LuxID Pro account.

LuxID Pro is particularly relevant for:

  • Organisations whose employees need to access LuxID-enabled Partner applications (RTL Play, CFL services, etc.) using their work identity
  • Organisations that want to restrict which LuxID Partner applications their employees can access (access policy is configurable in LuxID Pro)
  • Partners whose users are primarily enterprise employees (for example, a B2B SaaS application integrated with LuxID)

Supported corporate IdP types​

LuxID Pro supports federation with corporate identity providers via:

  • SAML 2.0 (Microsoft Entra ID / ADFS, Ping Identity, Shibboleth, and compatible systems)
  • OIDC (Okta, Microsoft Entra, Google Workspace, and compatible systems)

Domain-based routing​

When a user enters their email address on the LuxID login page, LuxID checks whether the email domain has a configured federation. If it does, the user is redirected to the corporate IdP login page instead of seeing the standard LuxID password form.

Example: a user enters marie.dupont@post.lu. LuxID detects that @post.lu is mapped to the POST Luxembourg corporate federation. The user is redirected to POST's Microsoft Entra ID login page, signs in with their corporate credentials, and is redirected back to LuxID, which then issues a standard LuxID token to the Partner application.

The Partner application is unaware of this routing - it initiates a standard OIDC authorisation request and receives a standard LuxID token.

Token claims for federated users​

When a user authenticates via LuxID Pro, the ID Token contains additional custom claims identifying the federation and organisation:

{
  "iss": "https://login.luxid.lu",
  "sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
  "aud": "app_rtlplay_prod",
  "iat": 1748477300,
  "exp": 1748480900,
  "auth_time": 1748477300,
  "acr": "urn:luxid:acr:level:substantial",
  "amr": ["pwd", "otp"],
  "email": "marie.dupont@post.lu",
  "email_verified": true,
  "name": "Marie Dupont",
  "given_name": "Marie",
  "family_name": "Dupont",
  "luxid_federation_realm": "post.lu",
  "luxid_organization": "POST Luxembourg"
}
ClaimTypeDescription
luxid_federation_realmstringThe federation realm (routed email domain) the user authenticated through, e.g. "post.lu". Present only for federated users
luxid_organizationstringName or identifier of the organisation the user federated through. Present only when luxid_federation_realm is present

These claims are present only when the user authenticated via a LuxID Pro federation. For standard (consumer) LuxID users, both claims are absent.

Access control with federation claims​

Partner applications can use the luxid_federation_realm claim to implement realm-based access control:

function authoriseEmployee(idTokenClaims, allowedRealms) {
  const realm = idTokenClaims.luxid_federation_realm;
  if (!realm) {
    return { allowed: false, reason: 'not_enterprise_user' };
  }
  if (!allowedRealms.includes(realm)) {
    return { allowed: false, reason: 'realm_not_permitted' };
  }
  return { allowed: true };
}

amr and acr for federated users​

The acr and amr claims in a federated token reflect the assurance level and methods that LuxID can verify from the corporate IdP's assertion. LuxID maps the corporate IdP's stated assurance level to the eIDAS scale where possible.

If the corporate IdP does not provide assurance level information, LuxID defaults to "substantial" when MFA was confirmed, or "low" when only single-factor authentication was confirmed.

LuxID Pro configuration​

Setting up a LuxID Pro enterprise federation is not self-service with LuxID. The onboarding process involves:

  1. Contact LuxID to request a LuxID Pro federation.
  2. Provide your organisation's IdP metadata (SAML metadata XML, or OIDC discovery URL).
  3. Provide the list of email domains to route through the federation (e.g. post.lu, post.group).
  4. Agree access policies: which LuxID Partner applications your employees can access through the federation.
  5. LuxID configures the federation and provides you with the SP metadata (SAML) or client credentials (OIDC) to configure on your corporate IdP.
  6. Test in UAT (login-uat.luxid.lu) before promoting to production.

There is no per-Application configuration required on the Partner side. Once the federation is live, any LuxID Partner application receives federated tokens automatically for users whose email domain matches the federation.

Employee access policies​

Organisations using LuxID Pro can restrict which LuxID Partner applications their employees can access through the federation. For example, POST Luxembourg could configure its federation to allow employee access to RTL Play and CFL services but not to other LuxID Partners.

Access policies are configured during the LuxID Pro onboarding process. Changes to policies require contacting LuxID.

SSO and session logout​

Consumer SSO logout​

Clearing your own application session does not end the LuxID session - so SSO can silently re-authenticate the user on their next visit. LuxID does not expose an OIDC end_session_endpoint and does not implement RP-Initiated Logout: as the shared SSO authority for many Partners, LuxID does not let one application terminate the session that other Partners rely on. Instead, if the user explicitly wants to end their LuxID session, redirect them to:

GET https://login.luxid.lu/auth/logout?client_id=<your_client_id>

LuxID renders a logout confirmation screen showing your application name (from the client_id), and the user decides whether to end the LuxID session. Doing so invalidates SSO for all applications in the same Sphere. See Session management.

Federated (LuxID Pro) logout​

For federated users, LuxID also initiates a logout request to the corporate IdP where supported (SAML Single Logout, or OIDC RP-initiated logout). This terminates the corporate session as well as the LuxID session.

Security and privacy notes​

sub is Sphere-scoped. In consumer SSO, the sub value is the same across all applications in the same Sphere for a given user. This is intentional and enables correlation within a Sphere (for example, a user's MyPost sub matches their Sphere-shared sub in another application). Cross-Sphere correlation is not possible.

Federated sub is still LuxID-assigned. Even for LuxID Pro users, the sub in the token is assigned by LuxID, not derived from the corporate IdP's identifier. This ensures that Partners cannot correlate LuxID Pro users with their corporate directory identifiers.

Session cookie security. The LuxID session cookie is HttpOnly, Secure, and SameSite=Strict. It is not accessible to JavaScript on any domain, including login.luxid.lu itself.

Access policy enforcement. LuxID Pro access policies are enforced server-side by LuxID. A Partner cannot circumvent the policy by modifying its authorisation request.

GDPR for federated identities. When a user authenticates via LuxID Pro, the corporate organisation (as a data controller) is sharing employee identity attributes with LuxID. Ensure that your organisation's employee privacy notice covers this use of identity data, particularly if employees are accessing consumer Partner applications (RTL Play, CFL services) using their corporate credentials.

Corporate IdP setup cookbook​

Each corporate IdP integrates with LuxID via either OIDC or SAML 2.0 federation - LuxID supports both protocols. The corporate IdP administrator and the LuxID Partner administrator (the person responsible for the LuxID integration on the organisation's side) work together: the IdP admin registers LuxID as a relying party on the corporate side, and LuxID configures the matching federation on the LuxID side based on the metadata or OIDC details the Partner provides.

The general setup flow for any corporate IdP is:

  1. LuxID Partner administrator submits the corporate IdP metadata or OIDC discovery URL to LuxID to register the federation.
  2. Choose OIDC or SAML 2.0.
  3. Provide the corporate IdP's discovery URL (OIDC) or metadata URL (SAML 2.0).
  4. Configure domain routing: specify which user-email domains route to this federation (e.g. contoso.com).
  5. Provide LuxID's SP metadata to the corporate IdP admin so they can register LuxID as a relying party on their side.
  6. Test the federation end-to-end in UAT (login-uat.luxid.lu) before promoting to production.

The subsections below give IdP-specific instructions for the most common corporate identity systems. For any system not listed, see Generic OIDC corporate IdP or Generic SAML 2.0 corporate IdP.

Availability and maturity. LuxID Pro is provisioned by LuxID on request - it is not self-service (there is no Console screen or Partner API to create a federation; see LuxID Pro operations below). The Microsoft Entra ID procedure is validated against a real configuration. The Google Workspace, Okta, ADFS, PingFederate / PingOne and generic procedures follow standard vendor patterns; the LuxID-specific values they reference (the SP metadata URL, ACS URL, SP entity ID, and OIDC callback URL) are confirmed by LuxID for your federation during onboarding. The OIDC callback URL follows the Entra pattern shown above (https://login.luxid.lu/api/services/luxid-federation-api/public/login/oauth2/code/...); LuxID provides the exact value, including the trailing path segment, for your federation. Always validate end-to-end in UAT before production.

Microsoft Entra ID (formerly Azure AD)​

Preferred protocol: OIDC. SAML 2.0 is also supported if required by policy.

Verified against the LuxID Pro - Entra ID configuration procedure (May 2026). Vendor admin-console paths change; if you find a mismatch, file a doc issue.

Entra IdP-side setup​

  1. In the Azure portal (opens in a new tab), open Microsoft Entra ID > App registrations > New registration.

  2. Name: LuxID PRO - PROD (use LuxID PRO - UAT for the sandbox tenant).

  3. Supported account types: Accounts in this organisational directory only (single-tenant).

  4. Redirect URI: select Web and enter exactly:

    https://login.luxid.lu/api/services/luxid-federation-api/public/login/oauth2/code/postlux

  5. Register, then note the Application (client) ID and the Directory (tenant) ID.

  6. Certificates & secrets > Client secrets > New client secret. Pick an expiry that fits your rotation policy. Copy the value immediately - Entra will never show it in plain text again.

  7. Token configuration > Add optional claim > ID token. Add:

    • acrs (carries the Authentication Context if you use Conditional Access - see steps 9-11)
    • email

  8. API permissions > Add a permission > Microsoft Graph > Delegated permissions. Add the four standard OIDC scopes:

    • openid
    • profile
    • email
    • offline_access

    Grant admin consent if your tenant requires it.

  9. (Optional, for stronger auth on sensitive operations) Identity > Conditional Access > Authentication contexts > New. Define an Authentication Context (for example C1) for the operation class you want to protect.

  10. (Optional) Identity > Conditional Access > Authentication strengths > New. Define an Authentication Strength (for example Authentication Strength C1). Typical allowed combinations: password + Microsoft Authenticator (push) or password + OATH software token.

  11. (Optional) Identity > Conditional Access > Policies > New. Bind the Authentication Context to the Authentication Strength: target the LuxID Authentication Context as the Resource and require the matching Authentication Strength as the Access control.

If your organisation uses groups or app roles to gate access, configure those under Enterprise applications > [your LuxID PRO app] > Users and groups.

LuxID-side setup​

  1. The LuxID team will configure the federation as OpenID Connect.
  2. Discovery URL: https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration (replace <tenant-id> with the Directory (tenant) ID noted above).
  3. Client ID: the Application (client) ID from the Entra app registration.
  4. Client Secret: the client secret value.
  5. Scopes: openid profile email offline_access.
  6. Domain routing: provide each email domain whose users should be routed to this federation (e.g. contoso.com, contoso.onmicrosoft.com).
  7. Leave Attribute mapping at the default unless your organisation uses non-standard claim names.

Test login​

Open https://login-uat.luxid.lu, enter an email address matching the configured domain, and confirm you are redirected to the Microsoft sign-in page. After corporate authentication, verify that the returned LuxID token contains luxid_federation_realm and luxid_organization claims.

Common pitfalls​

  • Client secret expiry: Entra secrets expire (1 year by default). Set a calendar reminder to rotate before expiry; an expired secret causes all federated logins to fail silently with invalid_client.
  • Missing optional claims: if email is not added as an optional ID-token claim, LuxID cannot map the user's email address and the federation fails. If you use Conditional Access, acrs is similarly required for context-aware decisions. Verify with the jwt.ms (opens in a new tab) token inspector.
  • Wrong redirect URI: the redirect URI is fixed - any deviation from the value in step 4 above produces AADSTS50011 (redirect mismatch).
  • Tenant-locked registrations: a single-tenant registration only accepts users from that tenant. Guest accounts in Entra B2B are not routed through this federation.
  • Conditional Access blocking the callback: ensure no Conditional Access policy is blocking the LuxID application's redirect-based flow.

Google Workspace​

Preferred protocol: SAML 2.0. Google Workspace can also act as an OIDC provider but SAML is the more commonly used path for workforce federation.

Google admin console-side setup​

  1. Sign in to the Google Admin Console (opens in a new tab) as a super administrator.
  2. Navigate to Apps -> Web and mobile apps -> Add app -> Add custom SAML app.
  3. Name the app (for example, LuxID).
  4. On the Google IdP Info step, download the IdP metadata XML - you will share this with LuxID.
  5. On the Service provider details step:
    • ACS URL: the LuxID SAML Assertion Consumer Service URL (provided by LuxID during onboarding).
    • Entity ID: the LuxID SP entity ID (provided by LuxID during onboarding).
    • Name ID format: EMAIL.
    • Name ID: Primary email.
  6. On the Attribute mapping step, add:
    • Google attribute Primary email -> App attribute email
    • Google attribute First name -> App attribute given_name
    • Google attribute Last name -> App attribute family_name
  7. Click Finish. Then, under User access, set the service status to ON for everyone (or restrict by organisational unit as needed).

LuxID-side setup​

  1. The LuxID team will configure the federation as SAML 2.0.
  2. IdP metadata: upload the Google IdP metadata XML downloaded in the step above.
  3. Domain routing: enter the Google Workspace domain (e.g. example.lu). Add any additional domains if your Workspace has multiple primary domains.
  4. Leave attribute mapping at the default (email, given_name, family_name should resolve automatically if the Google attribute mapping was configured correctly).
  5. Save.

Test login​

Navigate to https://login-uat.luxid.lu, enter an email address on the Workspace domain, and confirm you are redirected to the Google sign-in page. After Google authentication, verify the luxid_federation_realm claim appears in the resulting LuxID token.

Common pitfalls​

  • Service status OFF: The most common failure - the custom SAML app defaults to OFF for everyone in Google Admin Console. Users receive a Google error page ("This app is not available") rather than a LuxID error. Set it to ON for at least a test group first.
  • Name ID format mismatch: If Name ID format is set to X509_SUBJECT instead of EMAIL, the federation cannot map users correctly.
  • Certificate rotation: Google periodically rotates its signing certificate. If Google pushes a certificate rotation and LuxID holds the old metadata XML, SAML signature validation fails. Provide fresh metadata to LuxID after a Google certificate rotation.
  • Multi-domain Workspaces: If your organisation has multiple primary domains in Google Workspace, each domain must be added to the domain-routing list with LuxID.

Okta​

Preferred protocol: OIDC. SAML 2.0 is also supported.

Okta admin-side setup​

  1. In the Okta Admin Console, navigate to Applications -> Applications -> Create App Integration.
  2. Select OIDC - OpenID Connect -> Web Application -> Next.
  3. Name the integration (for example, LuxID).
  4. Under Sign-in redirect URIs, enter the LuxID OIDC callback URL.
  5. Under Sign-out redirect URIs, enter the LuxID post-logout redirect URI if federated SLO is required.
  6. Click Save. Note the Client ID and Client secret on the application's General tab.
  7. Under Assignments, assign the users or groups who are permitted to authenticate through this integration. Unassigned users receive an Okta error and cannot federate.

LuxID-side setup​

  1. The LuxID team will configure the federation as OpenID Connect.
  2. Discovery URL: https://<your-okta-domain>/.well-known/openid-configuration (replace <your-okta-domain> with your Okta org domain, e.g. your-company.okta.com or a custom domain).
  3. Client ID and Client Secret: from the Okta application's General tab.
  4. Scopes: openid profile email.
  5. Domain routing: the email domain(s) of employees who should route through this federation.
  6. Save.

Test login​

Navigate to https://login-uat.luxid.lu, enter an email on the configured domain, and confirm redirection to the Okta sign-in page. After Okta authentication, inspect the LuxID token and confirm luxid_federation_realm carries the routed domain and luxid_organization carries the expected organisation.

Common pitfalls​

  • Unassigned users: If a user is not assigned to the Okta application, Okta rejects the authentication with a generic error. Ensure group assignments are broad enough to cover all employees who need LuxID access.
  • Custom Okta domains: If the organisation uses a custom domain (e.g. sso.example.lu instead of example.okta.com), the discovery URL must use the custom domain, not the default Okta URL.
  • Okta-to-Okta federation: Some organisations have a complex Okta topology (hub-and-spoke). Confirm which Okta org (the authoritative one, not a delegated one) should be registered with LuxID.
  • email scope not returning email: In Okta, the email claim is only populated if the user's Okta profile has a primary email set. Verify this in the Okta user profile before testing.

ADFS (active directory federation services)​

Protocol: SAML 2.0 (ADFS's native federation protocol). ADFS does not support OIDC discovery in a form compatible with most OIDC-native federation setups.

ADFS admin-side setup​

  1. On the ADFS server, open AD FS Management -> Relying Party Trusts -> Add Relying Party Trust.
  2. Choose Claims aware -> Start.
  3. Select Import data about the relying party published online or on a local network and enter the LuxID SP metadata URL.
  4. Click through the wizard to complete the trust. ADFS will read the entity ID, ACS URL, and certificate from the metadata.
  5. After the trust is created, open its Properties -> Issuance Transform Rules -> Add Rule.
  6. Choose Send LDAP Attributes as Claims and create a rule mapping:
    • LDAP attribute E-Mail-Addresses -> Outgoing claim email
    • LDAP attribute Given-Name -> Outgoing claim given_name
    • LDAP attribute Surname -> Outgoing claim family_name
  7. Export the ADFS token-signing certificate (DER format) or download the ADFS federation metadata XML from https://<adfs-host>/FederationMetadata/2007-06/FederationMetadata.xml.

LuxID-side setup​

  1. The LuxID team will configure the federation as SAML 2.0.
  2. IdP metadata: provide the ADFS Federation Metadata XML URL (https://<adfs-host>/FederationMetadata/2007-06/FederationMetadata.xml) or upload the XML file directly.
  3. Domain routing: the Active Directory domain(s) whose users should route through this federation (e.g. company.lu).
  4. Save.

Test login​

Navigate to https://login-uat.luxid.lu, enter a corporate email address, and confirm redirection to the ADFS sign-in page (typically the Windows Integrated Authentication prompt or the ADFS form sign-in page). Verify the luxid_federation_realm claim in the resulting token.

Common pitfalls​

  • Clock skew: SAML assertions have a short validity window (typically 5 minutes). If the ADFS server clock and the LuxID server clock differ by more than 2-3 minutes, SAML assertions are rejected as expired. Ensure both systems synchronise to an NTP source.
  • Token-signing certificate rotation: ADFS auto-rotates its token-signing certificate. When rotation occurs, the old certificate is revoked and signatures from the new certificate fail validation until LuxID's cached metadata is refreshed. Ask LuxID to configure periodic metadata refresh or use a metadata URL (rather than a static XML upload) so rotation is picked up automatically.
  • Kerberos / Windows Integrated Authentication: If ADFS is configured for WIA, browsers outside the corporate network cannot complete authentication (WIA is intranet-only). External employees need the ADFS form sign-in fallback enabled, or access via a VPN.
  • ADFS 2012 R2 / older versions: Older ADFS versions have limited SAML attribute release support. Verify that your ADFS version supports the claim types required (email, given_name, family_name). ADFS 2019 or later is recommended.

Ping (PingFederate / PingOne)​

Protocol: OIDC or SAML 2.0. The Ping portfolio spans several products - identify which product the organisation is using before starting:

  • PingFederate: on-premises or private-cloud federation server. Supports both OIDC and SAML 2.0. The most common enterprise deployment.
  • PingOne: Ping's cloud-hosted workforce identity service. Supports both OIDC and SAML 2.0.
  • PingAccess: access management proxy - not an IdP. If the customer mentions PingAccess, clarify that PingFederate or PingOne is the relevant system for LuxID federation.

Setup outline​

The Ping-side configuration follows the same pattern as other IdPs:

  1. Register LuxID as a Service Provider (SAML 2.0) or OAuth client (OIDC) in PingFederate/PingOne.
  2. For SAML 2.0: use LuxID's SP metadata URL to auto-populate entity ID and ACS URL. Configure attribute mapping for email, given_name, family_name.
  3. For OIDC: create a new OAuth client, set the redirect URI to the LuxID callback URL, and note the Client ID and Secret.
  4. Provide the PingFederate metadata URL or OIDC discovery URL (https://<ping-host>/<context-root>/.well-known/openid-configuration) to LuxID so the federation can be added on the LuxID side (SAML 2.0 or OIDC, as appropriate).
  5. Configure domain routing and test in UAT.

Common pitfalls​

  • Multiple Ping products in the same organisation: Some enterprises run both PingFederate and PingOne in different roles. Confirm with the customer's IAM team which system holds the authoritative employee identity for the domains to be federated.
  • PingFederate adapter chains: PingFederate authentication policies can include multiple adapters (HTML form, Kerberos, certificates). Ensure the adapter chain terminates and releases attributes to LuxID even when the user authenticates via a secondary adapter.
  • PingOne directory vs. external directory: PingOne can use its built-in directory or proxy to an external Active Directory. If using an external directory, confirm that given_name and family_name attributes are mapped into the PingOne user schema and included in outbound assertions.

Generic OIDC corporate IdP​

For any corporate IdP that supports OIDC discovery and is not listed above, the integration pattern is identical across all LuxID-side steps.

What you need from the corporate IdP admin​

  • OIDC Discovery URL: the .well-known/openid-configuration endpoint for the corporate IdP (e.g. https://sso.example.com/.well-known/openid-configuration).
  • Client ID: the identifier assigned to LuxID in the corporate IdP's OAuth client registry.
  • Client Secret: the corresponding secret.
  • Scopes: at minimum openid profile email; add any scopes required to release given_name and family_name.

LuxID-side steps​

  1. Federations -> Add Federation -> OpenID Connect.
  2. Enter the Discovery URL, Client ID, Client Secret, and Scopes.
  3. Set Domain routing to the email domain(s) covered by this federation.
  4. Verify that the attribute mapping resolves email, given_name, family_name from the IdP's token claims.
  5. Save and test in UAT.

If the corporate IdP uses non-standard claim names (e.g. upn instead of email), configure the attribute mapping rules with LuxID to translate from the IdP's claim names to LuxID's expected names.

Generic SAML 2.0 corporate IdP​

For any corporate IdP that supports SAML 2.0 and is not listed above.

What you need from the corporate IdP admin​

  • IdP Metadata XML: either a URL to the live metadata endpoint or a static XML file containing the IdP's entity ID, SSO endpoint URL, and signing certificate.
  • Attribute release confirmation: confirm that the IdP releases email (or equivalent), given_name, and family_name in SAML assertions destined for LuxID.

What to provide to the corporate IdP admin​

  • LuxID SP Metadata: the LuxID SP metadata URL or XML file (provided during LuxID Pro onboarding).
  • The IdP admin uses this to register LuxID as a trusted relying party on their side.

LuxID-side steps​

  1. Federations -> Add Federation -> SAML 2.0.
  2. Upload the IdP metadata XML or provide the metadata URL.
  3. Set Domain routing.
  4. Configure attribute mapping if the IdP uses non-standard attribute names.
  5. Save and test in UAT.

Domain-based routing​

LuxID routes users to the correct corporate IdP based on the email domain entered at the Universal Login sign-in page. The routing is configured per federation entry with LuxID.

How it works:

  1. The user types their email address (e.g. alice@post.lu) on the LuxID login page.
  2. LuxID extracts the domain part (post.lu) and checks whether it matches a configured federation.
  3. If a match is found, the user is redirected to that corporate IdP's sign-in page.
  4. If no match is found, the user continues to the standard LuxID password authentication flow.

Routing rules:

  • A domain (e.g. post.lu) can only be assigned to one active federation at a time. Assigning the same domain to two federations simultaneously is not permitted.
  • Subdomains are not matched automatically: routing post.lu does not match internal.post.lu. Add each subdomain explicitly if needed.
  • Users with email domains that are not mapped to any federation see the standard LuxID login form. They can still sign in with a LuxID Account if they have one.
  • Test routing before going live: use https://login-uat.luxid.lu and enter a test email on the domain to verify the redirect fires correctly.

Token claims set after federated sign-in​

When a user authenticates via a LuxID Pro federation, the LuxID ID Token contains additional claims beyond the standard OIDC set. See Token Claims for Federated Users above for the full claim table.

Example excerpt showing the federation-specific claims:

{
  "luxid_federation_realm": "post.lu",
  "luxid_organization": "POST Luxembourg"
}

The corporate IdP type used for a federation is configured with LuxID during onboarding; it is not exposed as a token claim. LuxID Pro supports the following corporate IdP types:

Corporate IdP
Microsoft Entra ID (Azure AD)
Google Workspace
Okta
Microsoft ADFS
PingFederate
PingOne
Any SAML 2.0 IdP
Any OIDC IdP

These claims are absent for standard (consumer) LuxID users who authenticated without a federation.

Federation lifecycle​

Suspending a federation​

A federation can be suspended with LuxID without deleting it. While suspended:

  • New authentication attempts from users on the routed domains fail. The user sees the standard LuxID login form and cannot complete sign-in via the corporate IdP.
  • Existing LuxID sessions (users already signed in) remain valid until they expire naturally. Once the session expires, the user cannot re-authenticate via the suspended federation.
  • The luxid_federation_realm and luxid_organization claims in tokens issued from existing sessions remain unchanged until those sessions expire.

Suspension is appropriate for temporary maintenance windows or when investigating a security incident on the corporate IdP side.

Reactivating a federation​

Reactivate the federation with LuxID once the underlying issue is resolved. After reactivation, domain routing resumes and users can authenticate again. No changes are required on the corporate IdP side.

Removing a federation​

Deleting a federation with LuxID permanently removes the domain routing and all associated configuration. This action cannot be undone.

After deletion:

  • Users whose email domain was routed to the deleted federation can no longer sign in via federation. They see the standard LuxID login form.
  • If those users have a separate LuxID password (i.e. they existed before the federation was set up, or set a password through account management), they can still sign in with their LuxID password.
  • If users were created only via the federation and have no LuxID password, they cannot sign in until they complete a password-reset flow using their email address.
  • The luxid_federation_realm and luxid_organization claims in any tokens that are still within their validity window (i.e. not yet expired) become stale. They reference a federation that no longer exists. Partner applications that rely on luxid_organization for access control should treat unrecognised organisation values as unauthorised.

Rotating corporate IdP credentials​

When the corporate IdP admin rotates the client secret (OIDC) or token-signing certificate (SAML), submit the new value to LuxID before the old credentials expire. Recommended approach: send LuxID the new credentials and confirm the update, then revoke the old credentials on the corporate IdP side.

LuxID Pro operations​

This section answers the operational questions an enterprise IdP administrator asks before and after going live.

Fully LuxID-operated - no self-service​

LuxID Pro federation is operated entirely by LuxID. There is no Console screen and no Partner API endpoint to create, edit, suspend or delete a federation - every lifecycle action (create, suspend, reactivate, delete, rotate credentials, change domain routing, change the application allowlist) is performed by LuxID in response to a request via LuxID. Plan your change windows accordingly: federation changes are not instantaneous self-service operations.

First federated login - account provisioning and linking​

On a user's first successful login through a federation, LuxID provisions or links a LuxID Account keyed on the email address asserted by the corporate IdP:

  • If no LuxID Account exists for that email, LuxID creates one just-in-time from the federated assertion (no password is set; the user authenticates only through the corporate IdP).
  • If a LuxID Account already exists with that email (for example, the user previously created a consumer LuxID Account), LuxID links the federated identity to the existing account rather than creating a duplicate.

Because provisioning is keyed on email, the corporate IdP must release a verified email claim (OIDC email) or attribute (SAML email). Without it the federation cannot resolve a user.

Domain verification​

Domain routing captures every LuxID login on a claimed email domain (for example contoso.com) and sends it to the corporate IdP - a significant security boundary. Before LuxID routes a domain to your federation, it verifies that your organisation controls that domain. . Routing a domain you do not control is not possible.

Deprovisioning when an employee leaves​

Because authentication is delegated, disabling or deleting a user in the corporate IdP immediately prevents new federated sign-ins for that user - LuxID cannot complete a federation login the corporate IdP rejects. However, two things outlive the corporate-IdP change and must be considered:

  • Standing LuxID sessions established before deprovisioning remain valid until they expire (LuxID does not poll the corporate IdP mid-session).
  • Active refresh tokens issued to Partner applications continue to work until they expire or are revoked.

For immediate cut-off of a deprovisioned user's access to a specific Partner application, revoke that application's tokens (see Revocation). LuxID does not currently offer SCIM-based provisioning/deprovisioning; deprovisioning propagates through the delegated-authentication model described above.

Validated IdP support​

The Microsoft Entra ID path is validated against a real configuration (see the cookbook above). Google Workspace, Okta, ADFS and PingFederate / PingOne are supported through their standard OIDC or SAML 2.0 federation patterns; any compliant OIDC or SAML 2.0 corporate IdP can be federated via the generic procedures. Confirm support for a specific product and version with LuxID during onboarding.

Mise à jour le 2026-07-03
Sur cette page