SAML Group Claims and Portal-Tier Tokens After an IdP Migration

Both candidates live in the SAML assertion, but they fail differently.

Hypothesis A - nested groups are not flattened. Entra ID emits the groups a user is a direct member of (subject to the claim configuration). If GIS_Publishers was previously assigned directly to 210 people and is now a child of departmental groups, the assertion will contain the departmental group but not GIS_Publishers. The 38 users who still work are the ones with a direct membership; 172 are nested. The same explanation covers GIS_Admins being invisible.

Hypothesis B - the groups claim is being dropped entirely for heavy users. Entra ID caps the number of group values in a SAML assertion (150 for SAML, 200 for JWT). Users exceeding the cap do not get a truncated list - the claim is omitted. If the 172 failing users belong to many departmental groups, they may be receiving no groups claim at all, which would also produce Viewer fallback and an absent admin group.

The distinguishing evidence: decode one failing user's actual SAML assertion with a SAML tracer or the enterprise app's sign-in log. If the groups attribute is present but omits GIS_Publishers, it is nesting. If the attribute is absent altogether, it is the over-limit drop. Do this for two or three failing users before changing anything - it takes ten minutes and prevents "fixing" the wrong layer.

Regardless of cause, the immediate mitigation is to restore administrative access through a documented break-glass path so that anyone can change settings at all.

Restore access first. If a built-in administrator account exists, use it to regain control; if not, this is an escalation to Esri Support, which is why every portal needs a documented break-glass account with credentials in a safe. Do not create a new enterprise mapping while locked out - you cannot test it.

IdP fix (Entra ID enterprise application):

• Change the groups claim from "All groups" to Groups assigned to the application, then assign only GIS_Publishers, GIS_Viewers, GIS_Admins, and any other consumed groups to the app. This solves both hypotheses at once: it flattens the relevant groups into the token and keeps the claim small regardless of how many departmental groups a user belongs to.
• If the organization insists on emitting all groups, restrict the claim to security groups and monitor claim size; the 150-value limit will still bite eventually.
• Alternatively, emit an app role or a dedicated attribute (for example a gisRole claim maintained by group-based assignment) and map roles from that, so role logic lives in one place.

Portal fix:

• Confirm the portal groups still exist with the exact enterprise group names; SAML group names are matched as received, and a rename during migration silently breaks the mapping.
• Consider not mapping any group to Administrator. Map GIS_Publishers to Publisher, and grant Administrator to a small number of named individuals plus the break-glass account. A broad group-to-Administrator mapping is how a single IdP misconfiguration becomes a full outage.
• After the change, test with one user from each cohort, then verify group membership updates propagate on the next sign-in (existing sessions may need to sign out).

Finally, handle the departed contractors: reassign their content to a group-owned account, then disable the built-in accounts.

The app is using the wrong token issuer. When a service is secured with server-tier (GIS-tier) security, a token from the ArcGIS Server token endpoint is accepted. When the service is switched to portal-tier security, the server validates tokens against the portal, and a server-issued token is not recognized - hence a uniform rejection for that app while interactive portal users are unaffected. Nothing is wrong with the app's credentials; the trust boundary moved.

The correct fixes, in order of preference:

1. OAuth 2.0 application registration in the portal. Register an app to obtain a client ID and secret, associate it with a dedicated named user or app identity, and have the app request portal tokens. Store the secret in a vault, never in code, and rotate it. This is the supported pattern for server-side integrations and gives you revocability and auditability.
2. Dedicated service account with generateToken. If the app cannot implement an OAuth flow, call the portal's /sharing/rest/generateToken with a dedicated named-user account that holds only the privileges required, and share the service with that account (or a group it belongs to). Set the shortest workable token lifetime and implement refresh, since default lifetimes are measured in minutes.
3. Avoid anonymous exposure as a shortcut. Re-securing the service as public to unblock the app would trade an authentication problem for a data-exposure problem.

Operationally: monitor 498 responses as a distinct alert class, document which services are portal-tier versus server-tier, and require a change ticket note whenever a service's security tier changes - that one-line note would have prevented this outage.