A company refreshes its IdP schema and later Grafana users log in successfully but lose access to folders they previously owned.
A Grafana SSO login succeeds and folder permissions look empty because the IdP moved team claims under groups and the role mapping still reads the previous flat team attribute
Authentication is fine, yet authorization collapses because the dashboard role mapper still expects the old claim shape.
Scenario
What to check first
- Identify the primary failure signal in the The User Logged In Correctly With Claims the Mapper No Longer Understood scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Inspect the live token claim structure before editing Grafana teams or reassigning permissions manually.
Questions worth viewing together
Community-field security problem inspired by Grafana community threads where role mapping broke after IdP claims moved into a different attribute struct... SSO failures often hide in claim-shape drift after an IdP update, not in the login flow itself.
Teams often blame stale sync jobs when the role mapper simply targets the wrong claim path.
OIDC-backed RBAC should be revalidated any time the IdP changes claim nesting or naming.
Similar cases seen in the field