Keeping campus identity providers in sync with application roles can go sideways quickly—especially when you introduce per-action audit requirements. This post outlines the guardrails we applied while wiring UMBC’s Shibboleth IdP to the CyberRange portal.
Start with a role contract
Before writing code, agree on a contract with the identity team. We specified:
- Canonical attribute names (
urn:oid:1.3.6.1.4.1.5923.1.5.1.1for eduPersonAffiliation) - Allowed values per attribute and what scopes they unlock
- Expected NameID format (transient vs. persistent)
Map to scopes, not UI roles
We maintained a scopes.json that translated IdP roles to backend capabilities. The UI simply asked the API: “Does this user have labs:power:cycle?” That separation prevented awkward UI drift when the identity team renamed groups.
Harden the session lifecycle
- Cookies set to
SameSite=strict,HttpOnly, andSecure - AES-encrypted session payload with rotating keys stored in HashiCorp Vault
- CSRF double-submit tokens on all mutation routes
Audit everything
We streamed sensitive events (console open, template clone, role change) to Mongo change streams and persisted them in Postgres for reporting. Every audit record links to the original SAML assertion, making compliance reviews painless.
Wrap-up
The end result: faculty now approve lab access with confidence that session state and RBAC scopes move in lockstep with campus identity.