A customer account may access personal information. An employee account may reach internal applications and manage customer identities. An administrator can change the rules for everyone else. Those are different trust contexts, even when all three identities belong to the same person.
Classify identities for a reason
Classification should change the policy that applies, not merely the dashboard label. Decide which attributes distinguish customer, employee and administrator profiles, how a user moves between categories and whether non-employees may become administrators. Keep the rule explicit and auditable.
WebFrolic documents these three classifications and separate dashboards, with configurable profile attributes, authenticator requirements, network rules and session controls. Every relevant path should evaluate the intended classification rather than rely on the page the user opened.
Tune assurance to the action and context
Employees may need stronger authenticators for internal resources. Administrators may require a higher threshold for configuration changes. Customers may have different enrolment options while still protecting sensitive account changes. The policy should follow risk and user needs rather than assume one category is inherently trustworthy.
Test transitions: a customer becomes an employee, an employee leaves the employee group, or a user gains an administrator role. Verify when policy changes take effect and what happens to active sessions and credentials. Classification must not silently retain old privileges.
Keep authorisation separate from authentication
A strong sign-in proves something about the authentication event; it does not grant every operation. Authorisation must evaluate role assignments, resource scope, tenant context and network rules. Identity class shapes policy but does not replace resource-level checks.
Review high-risk actions directly: editing authenticator configuration, assigning roles, impersonating a customer, changing tenant settings and accessing sensitive resources. For each, state the required identity class, assurance level and scope, then test denial paths.
Make policy understandable
A complex policy is hard to troubleshoot when the UI returns only a generic denial. Explain the relevant policy class or missing requirement without disclosing sensitive internal details to an untrusted requester.
Record which policy was evaluated and which condition determined the outcome. That context helps reviewers understand why an administrator was challenged differently from a customer and makes policy drift easier to diagnose.
What this comes down to
Define the purpose and transition rules for each identity class.
Configure assurance, network and session controls by risk.
Evaluate authorisation at resource and operation boundaries.
Test category transitions and record policy decisions.