A role name does not define a permission until it is translated into actions on resources. In an authentication service, reading a report, exporting it, approving a change and executing that change have different consequences. Build a small explicit access matrix before assigning people to roles.
Start with tasks and resources
For each tenant, list domain inventory, aggregate reports, proposals, DNS execution and user administration. Decide who may read, export, propose, approve, execute and manage membership. Customer staff might read their own reports; analysts might investigate and propose; designated approvers authorize business impact; operators execute approved changes. These are proposed role boundaries, not claims about a specific product.
OWASP recommends least privilege, default denial and permission checks on every request. A role should therefore be evaluated with tenant scope and resource identity, not as a global Boolean flag. Authentication establishes the principal; authorization decides whether that principal may perform this action now.
Separate approval from capability
An operator's technical access does not automatically authorize every business change. Bind execution to the approved proposal and enforce any separation-of-duties requirements the customer adopts. If one person holds multiple roles, record the overlap and its compensating review instead of pretending two role names represent two independent people.
Keep permission administration separate from routine analysis where practical. A person who can grant themselves execution rights can defeat a nominal approval boundary. Define who may assign powerful roles, how those assignments are reviewed and what emergency access expires automatically. Avoid shared administrator accounts when individual accountability is required.
Exercise the access matrix
Suppose a reader can view reports in tenant A but attempts an export requiring a separately granted permission. A successful login and read do not establish export authority. Separately, an analyst who moved off the account may still have an old session; current membership and resource scope must be checked before that session retrieves another report. These are hypothetical permission cases, not a tested application policy.
Evaluate allowed and denied operations through the actual API, sessions, scheduled tasks and exports using authorized test identities. Include a valid scoped read so global denial is not mistaken for correct access control. Retain the effective permissions, test context and observed outcome; a neat matrix alone does not demonstrate enforcement.
Keep the lifecycle visible
Record the reason, tenant scope, approver and review date for role assignments. On a job change, remove old permissions instead of only adding new ones. Offboarding should revoke memberships and associated access paths, then confirm the principal can no longer retrieve artifacts or initiate work. Service identities need named owners and separate lifecycle reviews.
Review permission drift when customers, domain assignments or automation capabilities change. Compare effective permissions, including inherited groups, with the approved matrix. If a customer needs a temporary exception, define the precise operation, expiry and review record. Close the exception when the need ends. Roles are a maintenance mechanism, not a one-time proof that access remains safe.