SAML SP Login Fails for Nested Group Roles
A 12,000-employee company federates a vendor SaaS application with Okta using SAML 2.0 and SCIM 2.0. SP-initiated login fails for about 8% of users with an InvalidNameIDPolicy error; IdP-initiated login sometimes works. The vendor's metadata requires a persistent NameID and a single role attribute whose value must be exactly admin, analyst, or viewer. Okta currently sends NameID as the user's email and sends all Okta groups in the role attribute; the vendor takes the first value. Affected users belong to 25-40 AD-synced groups through nested memberships and often have both Sales-Admin and Sales-User. Meanwhile, SCIM creates users as active, but the vendor shows duplicate accounts because Okta's SCIM app was configured without a stable externalId, and some users change email after marriage. You need to fix login, make role assignment deterministic, and stop SCIM duplicates.
1. What is causing `InvalidNameIDPolicy`, and how should NameID be configured?
Read the worked answer
The SP is sending a NameIDPolicy in its AuthnRequest that requires a specific format, likely persistent, while Okta is releasing an email-format NameID. The SP rejects the assertion because the format does not match. IdP-initiated login can appear to work because the SP may not enforce the same policy when it did not initiate the request.
Compare the SP metadata and the actual AuthnRequest with Okta's SAML app settings. Set the NameID format to what the SP requires. If persistent is required, map the value to a stable employee identifier such as externalId or employee number, not email; email aliases and name changes make email unstable and can create a new vendor identity. Confirm the SP's ACS URL and audience also match. After changing NameID, test both SP-initiated and IdP-initiated flows with a user who has an email alias; do not assume the error is a certificate or signature issue.
2. How should the `role` attribute be made deterministic when users have many nested groups and conflicting role groups?
Read the worked answer
Sending every Okta group in a single multivalued role attribute lets the SP choose arbitrarily, so Sales-Admin and Sales-User can produce the wrong authorization. First define one authoritative role group per application, such as APP_Sales_admin, APP_Sales_analyst, and APP_Sales_viewer. Then use a group attribute statement with a regex filter that includes only those role groups, or assign only the role groups to the app and send app groups.
If a user can belong to more than one role group, resolve conflicts in Okta with group rules or a documented precedence, and do not rely on the SP to pick the first value. Validate that AD-synced nested memberships actually appear in Okta's user group list; if they do not, fix group sync before changing the SAML expression. Test the assertion with a SAML tracer for a user in both admin and user groups, and confirm the attribute contains exactly one allowed value.
3. How should SCIM be configured to prevent duplicate accounts when email addresses change?
Read the worked answer
SCIM matching must not depend on userName alone. Configure externalId in Okta's SCIM app to the immutable HR worker ID, and configure the vendor to match incoming users on externalId. Then an email change updates the existing vendor record instead of creating a new one. If the vendor also requires userName to be the email, it should treat it as a mutable attribute once the external identity is linked.
For existing duplicates, reconcile manually or with a one-time script: match by HR ID, link the correct records, and deactivate the extras. Turn on SCIM error monitoring and alert on create conflicts. Do not solve this by making email immutable in Okta if HR changes it; solve the matching problem with a stable key and test a rehire and a name-change scenario end to end.