Identity, Authentication, and Access Control
Authentication versus authorization
Authentication answers who: local Prism accounts (your break-glass access), Active Directory/LDAP directory services, or a SAML 2.0 identity provider. Authorization answers what: RBAC roles bound to users or groups through role mappings, then scoped by categories or Projects. The classic trap is assuming a directory service configured on Prism Element also applies to Prism Central - each appliance maintains its own directory, IdP, certificate, and local admin configuration.
Role mechanics
There are built-in roles (Super Admin, Prism Admin, Prism Viewer, plus more granular roles such as VM Admin, Network Admin, and Self-Service Admin in newer releases) and custom roles built from permission sets. A role mapping matches a directory group name or SAML group claim exactly; a typo produces a successful login with zero permissions, which is a favorite exam scenario. Category scoping limits an assignment to VMs carrying given categories, so a VM Admin scoped to env:dev cannot act on env:prod. Projects add multi-tenant separation on top.
SAML and directory notes
SAML assertions break when NTP drifts, when the Prism Central FQDN changes and the entity/ACS URLs no longer match, or when the IdP certificate expires. Keep a local account enabled for break-glass even after SSO is live, and remember that nested group evaluation may not behave as expected - test mappings before rollout.
Rule of thumb
Authenticate centrally, authorize narrowly: directory or IdP for identity, group-based role mappings for permissions, categories for scope - and never bind Super Admin to a directory group.