auditing-jit-provisioning-and-role-mappinglisted

# Auditing JIT provisioning and role mapping: the first login decides the role, from claims you did not issue Just-in-time provisioning creates a local account the first time someone logs in through a federated identity provider, and often updates that account's roles on every subsequent login, all from the claims in the login assertion. The claims, group memberships, an email, a domain, a department, come from the identity provider, not from you, so JIT hands account creation and role assignment to whatever the assertion says. That is fine when the mapping is tight and the claims are validated, and dangerous when either is loose. A claim-to-role mapping that grants more privilege than the claim should, or defaults every new user into a privileged role, elevates at first login. An email or domain claim trusted to auto-join a tenant or organization lets an attacker with a lookalike or attacker-controlled address land inside it. A JIT update that re-reads mutable claims every login can re-elevate or reassign an account an admin previously corrected. And any claim provisioned without validation, an unverified email, a group the attacker can influence, an unsigned or overtrusted assertion field, becomes an access grant. The audit follows a federated login into the account and roles it creates and checks that every claim is validated and every mapping is minimal. You audit this by logging in with shaped assertions and seeing what account and privilege you are given. ## When to u