Policy Awareness

PIM activation is governed by per-role policies in Microsoft Entra. The portal reads those policies, surfaces them in the UI as a per-role matrix, enforces them client-side at submit, and steps up authentication when a role requires a Conditional Access auth context.

What the matrix shows

For every eligible role, the matrix renders the requirements that apply:

Requirement	What you'll see	What it means
Justification	"Justification required"	A free-text reason is mandatory before submit
Ticket	"Ticket required"	A ticket system + ticket id is mandatory before submit
MFA	"MFA required"	The user must have a recent strong authentication event
Auth context	"Auth context required"	A Conditional Access auth context (claims challenge) must be satisfied
Approval	"Approval required"	The activation request goes to an approver instead of activating immediately
Max duration	"Up to N hours"	Cap applied to the requested duration

How the portal enforces policy

Justification and ticket

These fields are validated client-side before the activation request is sent. You'll see inline errors on missing fields and the Activate button stays disabled until every required field for every selected role is filled.

If multiple selected roles require the same fields, you only fill them once and the values are reused for the whole batch. If different roles need different ticket systems, the portal expands the form per role.

Maximum duration

Whatever duration you request is capped to the lowest applicable policy maximum at submit time. This eliminates "over-request" failures — you don't have to know each role's maximum to activate them in bulk.

MFA

The portal does not prompt for MFA itself; that is Microsoft's job. If MFA is required and your token doesn't reflect a recent strong-auth event, the activation request returns 400 / 403 with a claims challenge, which the portal handles via the same step-up flow described below.

Conditional Access auth context

If a role's policy references a Conditional Access auth context (an acrs claim such as c1, c2, etc.), the portal:

1. Detects the requirement from the role policy before submit.
2. Calls MSAL with a constructed claims parameter that requests the required acrs value.
3. Redirects you to login.microsoftonline.com to satisfy the auth context (this is where MFA, compliant device, etc. actually get evaluated).
4. Resumes the activation operation with the new token.
5. Threads the same claims into every subsequent token acquisition for the rest of the operation, so every Graph and ARM call satisfies the requirement without prompting again.

401 responses that come back with WWW-Authenticate: insufficient_claims — for example, because policy was tightened mid-flight or the auth context applies to a downstream resource — are also detected at the API client layer and resolved through the same step-up.

Approval

For approval-required roles, the activation request submits successfully but enters a Pending state. The portal:

• Tags the role with Pending in the active table.
• Captures the request id in the activity-details modal.
• Surfaces success / denial in the next refresh.

The portal does not currently poll for approval state changes. Refresh manually after your approver acts, or use the bell icon to see notifications you may have queued.

Policy fetch and cache

Policies are fetched in bulk on the first roles render, and cached in memory for 30 minutes per tenant. This avoids paying the policy round-trip on every activation.

For Entra roles, the portal uses tenant-root roleManagementPolicyAssignments queries to avoid per-Administrative-Unit permission issues that some directories enforce. For Groups and Azure Resources, per-policy fetches are made on first use.

A manual Refresh in the header invalidates both the role and policy caches.