Handling SAML Attributes and Mapping
SAML can carry user attributes along with authentication results. Knowing the naming differences and mapping tips makes operations smoother.
📄 Attribute Basics
Attributes like email, name, and roles can be embedded in the SAML Response for account linking and authorization.
Common attributes
- ✅ email: Used as login ID or notification address.
- ✅ givenName / surname: Used for display name.
- ✅ groups / roles: Used for access control.
🧩 Attribute Mapping
Map IdP-provided attribute names to your internal user fields.
Mapping tips
- 🔍 Attribute names and namespaces differ by IdP (AzureAD, Okta, Google Workspace).
- 🔍 Agree on required attributes up front; missing values can break login.
- 🔍 Verify values in test/staging; they may differ from production tenants.
⚙️ IdP Differences and Setup Tips
Attribute names/namespaces differ by IdP, so align expectations and document them up front.
Attribute Profile
SAML defines Attribute Profiles (e.g., X.500/LDAP) to standardize attribute names/namespaces. Using a standard profile improves interoperability.
- Refer to standard profiles (e.g., X.500/LDAP Attribute Profile) and align names/namespaces.
- If using IdP-specific custom attributes, document the SP mapping explicitly.
- Agree whether the integration follows a standard profile.
IdP specifics
- 🔧 AzureAD: URL-style EntityID; attributes often have unique namespaces.
- 🔧 Google Workspace: Uses its own namespace; attribute names may need adjustment.
- 🔧 Okta/Keycloak: Very flexible but many options; AttributeStatement scope is wide.
SP-side tips
- 🛠️ Document accepted attribute names and share with the IdP team.
- 🛠️ Define AttributeConsumingService in metadata when possible.
- 🛠️ Track tenant/env differences and share them with support teams.