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.