Generic SAML setup
When to use this page
Use this page when your tool asks for "SAML IdP configuration", "Identity Provider metadata", or "SAML SSO settings" and is not covered by a dedicated guide in Tool-specific integrations.
SAML requires a bilateral trust between LuxID (the Identity Provider) and your tool (the Service Provider). Both sides must be configured before a login attempt will succeed. Complete the steps on this page, then send your tool's Service Provider details to LuxID so LuxID can register the trust.
LuxID IdP metadata
The fastest way to configure SAML is to import the LuxID IdP metadata XML. The metadata contains the entity ID, SSO endpoint URLs, and the signing certificate in a single file.
| Environment | Metadata URL |
|---|---|
| Production | Download SAML metadata |
| UAT (sandbox) | Download SAML metadata |
If your tool supports metadata URL import, paste the appropriate URL directly into the field. The tool will fetch and parse the XML automatically.
If your tool requires a file upload, download the XML from the URL above and upload it.
If your tool requires manual field entry, extract the values from the XML as described in the sections below. The key elements to look for are EntityDescriptor[entityID], SingleSignOnService and X509Certificate.
LuxID rotates signing certificates periodically. If your tool imports metadata by URL, it can refresh automatically. If you uploaded a static file, you must re-download and re-upload the metadata after a certificate rotation. The LuxID team will notify registered partners before rotating certificates.
IdP entity ID
The LuxID IdP entity ID is:
https://login.luxid.lu/saml/sps/saml20idp-LUXID/saml20
This value appears in the metadata XML as the entityID attribute on the root EntityDescriptor element. Enter it in any field labelled "IdP Entity ID", "Issuer", or "Identity Provider Issuer". Read it from the metadata rather than hardcoding it from this page.
UAT entity ID:
https://login-uat.luxid.lu/saml/sps/saml20idp-LUXID/saml20
SSO service URL (IdP-initiated and SP-initiated)
LuxID supports the HTTP-POST and HTTP-Redirect bindings for the SSO service. Most tools default to HTTP-Redirect for the authentication request and expect HTTP-POST for the response assertion.
The SSO endpoint URLs are included in the metadata XML under SingleSignOnService. The exact URLs are environment-specific and are found in the metadata - do not hardcode them from this page as they may be updated.
If your tool requires you to enter the SSO URL manually, retrieve it from the metadata XML:
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://login.luxid.lu/..."/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://login.luxid.lu/..."/>
Use the HTTP-Redirect binding URL for the tool's "SAML SSO URL" field unless the tool's documentation specifies HTTP-POST.
Logout
LuxID does not support SAML Single Logout. There is no SingleLogoutService in the LuxID metadata. When a user signs out of your tool, clear the local session in the tool; LuxID does not propagate a logout to or from other services (this matches how LuxID handles OIDC logout - one service must not end the shared LuxID session). Ending the LuxID session itself is a user-driven action on LuxID, not something your tool triggers.
Signing certificate
LuxID signs SAML assertions and responses using an RSA certificate. The certificate is included in the metadata XML under KeyDescriptor use="signing" > X509Certificate.
Import the certificate from the metadata rather than copying it manually. Manual copy-paste of certificates is a common source of line-ending and whitespace errors that cause signature verification failures.
After importing, your tool should be configured to:
- Verify the signature on the SAML response - required
- Verify the signature on the SAML assertion - required
LuxID signs both the response and the assertion. Tools that only verify one of the two may reject valid assertions if their verification logic is strict.
Assertion consumer service (ACS) URL
The ACS URL is the endpoint in your tool where LuxID sends the SAML response after authentication. You must:
- Find the ACS URL in your tool's SAML SP configuration screen
- Whitelist it with LuxID by sending it to LuxID
The ACS URL format varies by tool. Common patterns:
| Tool | ACS URL pattern |
|---|---|
| ServiceNow | https://your-instance.service-now.com/navpage.do |
| Atlassian Cloud | https://auth.atlassian.com/login/callback?connection=... |
| Microsoft Entra (B2B federation) | https://login.microsoftonline.com/login.srf |
| Generic tool | Check the tool's SAML SP metadata under AssertionConsumerService |
Always use the ACS URL shown in the tool's SAML configuration screen. Do not construct it manually.
Service provider entity ID
Your tool has its own entity ID (also called Audience URI or SP entity ID). You must provide this to LuxID so LuxID knows which Relying Party is sending the authentication request.
Find your tool's SP entity ID in:
- The tool's SAML SP metadata XML under
EntityDescriptor[entityID] - The tool's SAML SSO settings screen (often labelled "Entity ID", "Audience URI", or "SP Issuer")
Send the SP entity ID, the ACS URL, and (if available) the full SP metadata XML to LuxID with the subject line: SAML SP registration - [Your Organisation] - [Tool Name].
NameID format
LuxID supports the following NameID formats. The recommended format for most integrations is emailAddress.
| NameID format | URI | When to use |
|---|---|---|
| Email address | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress | Default. Use when the tool identifies users by email |
| Persistent | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent | Use when the tool stores an opaque stable identifier; LuxID sends the sub equivalent |
| Unspecified | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified | Fallback; LuxID uses email address |
Configure the NameID format in your tool's SAML SP settings. If the tool's documentation does not specify, use emailAddress.
Signed assertion expectations
LuxID sends signed assertions within a signed response. Your tool must be configured to:
- Accept signed assertions (required)
- Accept signed responses (required)
- Use the LuxID signing certificate from the metadata to verify both signatures
If your tool has separate toggles for "Verify assertion signature" and "Verify response signature", enable both.
If your tool has a "Want Assertions Signed" setting in its SP metadata, set it to true. The LuxID team reads this from your SP metadata during onboarding.
Attribute statement layout
LuxID releases user attributes as a SAML Attribute Statement. The attributes included depend on your Claim Template - configured by LuxID during onboarding.
Standard attributes and their SAML names:
| Attribute name (in assertion) | Value | Notes |
|---|---|---|
email | User's email address | Always included; the primary identifier |
given_name | User's first name | Included when profile claims are enabled |
family_name | User's last name (surname) | Included when profile claims are enabled |
name | Full display name | given_name + space + family_name |
phone_number | Phone number in E.164 format | Included only if requested in onboarding |
sub | Stable opaque user identifier | Available on request |
age_over_16 | true or false | Defined in the schema but not currently offered by LuxID |
Requesting additional attributes: Contact LuxID to add attributes to your Claim Template.
Typical field mapping table
The following table maps common SAML tool field labels to the correct LuxID values.
| Typical tool field label | Value to enter |
|---|---|
| Identity Provider Entity ID / Issuer | https://login.luxid.lu/saml/sps/saml20idp-LUXID/saml20 |
| IdP Metadata URL | https://docs.luxid.lu/saml/luxid_idp_saml_metadata-prod.xml |
| SSO URL / Login URL | From metadata XML SingleSignOnService (HTTP-Redirect binding) |
| IdP Certificate / X.509 Certificate | From metadata XML X509Certificate |
| NameID format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Signing algorithm | RSA-SHA256 |
| Email attribute | email |
| First name attribute | given_name |
| Last name attribute | family_name |
| Display name attribute | name |
| Verify assertion signature | Enabled |
| Verify response signature | Enabled |
Exchanging SP metadata with LuxID
SAML requires both sides to trust each other before any login attempt will work. The LuxID team needs your SP details to configure the Relying Party trust on the LuxID side.
What to send to LuxID:
- SP entity ID (Audience URI)
- ACS URL (Assertion Consumer Service URL)
- SP metadata XML (preferred - contains all of the above plus your SP certificate if you sign AuthnRequests)
- Tool name and environment (production or UAT)
- NameID format preference
Use the subject line: SAML SP registration - [Your Organisation] - [Tool Name] - [Environment]
The LuxID team will confirm when the trust is configured and provide any additional IdP-side values you need (such as the exact SSO URL for your application's registration if it differs from the metadata).
Verification checklist
After configuring both sides, run through this checklist before going live.
- LuxID IdP metadata imported into the tool (by URL or file)
- SP entity ID and ACS URL confirmed with LuxID
- NameID format set to
emailAddress(or agreed alternative) - Assertion signature verification enabled in the tool
- Response signature verification enabled in the tool
- Test login with UAT metadata (
login-uat.luxid.lu) completes without error - The following attributes arrive in the tool after login:
email,given_name,family_name - User record created or matched correctly in the tool
- Switched to production metadata URL (
login.luxid.lu) before go-live - LuxID team notified of go-live date (recommended for enterprise integrations)
Related pages
- Before you start - prerequisites including Console registration
- Tool-specific integrations - per-tool guides for Atlassian, Microsoft 365, and ServiceNow
- SAML 2.0 Authentication - protocol deep-dive for developers
- Redirect and domain issues - troubleshooting common SAML errors