A global role may grant authority across resources or tenants. That can be necessary for platform operations, but it deserves controls beyond an ordinary assignment. The question is not only who has the role; it is under what conditions that role can be used.
Treat role assumption as a distinct decision
A user may sign in successfully without satisfying the requirement for a sensitive role. Model role assumption as a separate event with its own assurance requirement, network conditions and resource scope. This allows low-risk application use while raising the bar for high-impact operations.
WebFrolic documents role-associated network filters and configurable authenticator assurance requirements across the product. Use those controls together where appropriate and verify that the rule is evaluated at the moment the role becomes active.
Keep global authority narrow
“Global” should describe intended scope, not justify every permission. Review which operations truly require cross-resource authority, whether read and write permissions can be separated, and whether a service identity should perform a narrow automation task instead of a human using a broad role.
Make role ownership and assignment criteria explicit. A user should not be able to create an identity, weaken its assurance policy and assign it unrestricted authority through a chain of unchecked changes.
Combine network controls without treating them as identity
A network allow list can limit role use to an approved range, but an approved IP does not establish a person’s identity or prove the endpoint is safe. Maintain authentication, session policy and authorisation checks, and ensure a role cannot be assumed from an unintended network merely because it is assigned.
Shared offices, VPNs and proxies need careful modelling. Document network ranges, who maintains them and how emergency changes are approved. Log the matched rule and role-assumption result to help operators investigate.
Test high-consequence combinations
Test a strong user on an approved network, a strong user on a denied network, a user with insufficient assurance and a user without the role. Verify that each condition produces the intended result and useful audit evidence.
Repeat tests after role policy changes and new authenticator enrolment options. A policy that is secure in isolation can be undermined if another flow lets a user alter the factors used to satisfy the role’s requirement.
In practice
Evaluate assurance and network rules at role assumption.
Grant only operations that require global scope.
Keep identity, network and authorisation checks independent.
Test combinations of role assignment, assurance and network outcomes.