Identity architecture rarely becomes fragmented in one dramatic decision. It grows one reasonable decision at a time. A team starts with authentication. Then it adds lifecycle management, access requests, reviews, audit exports, customer support, tenant SSO and—more recently—machine and agent access. Each addition solves a real problem. The trouble begins when the pieces do not share a clear identity model, a common set of lifecycle rules or a dependable record of how access was granted.
The identity-house series tells that story in three pictures: the system as it often grows, the gap between customer and workforce identity, and a more coherent model built on one foundation.
1. Identity as built today: a house of additions
In the first illustration, authentication is the ground floor. Around it sit separately purchased or separately built capabilities: access requests, lifecycle and provisioning, access reviews, audit, support desks and agent access. They are connected with cables, keys, tokens and improvised supports.
This is not an argument that every company should use one vendor for everything. Specialist tools can be the right choice. The architectural question is whether the complete system remains coherent when those tools interact.
- Ownership fragments. One team owns login, another owns provisioning, and another owns the support process. No single view explains the whole access journey.
- Integrations become privileged infrastructure. Connectors need credentials and permissions to move data or change access. Those connections deserve the same attention as the systems they link.
- Exceptions are easy to leave behind. Temporary test accounts, shared support credentials and recovery shortcuts can continue to exist after the original reason has disappeared.
The core problem is not the number of tools. It is the gap between their identity records, policy decisions, lifecycle events and audit trails.
2. Customer and workforce identity: two houses, one person
Customer identity and workforce identity often mature along different paths. Workforce systems may centre on enterprise SSO, device signals, access requests, reviews and employee provisioning. Customer systems may grow around sign-in, profiles, consent, fraud controls, support and the needs of a public-facing application. B2B products add another layer when each customer brings its own identity provider and tenant administration model.
The bridge is where many of the difficult questions live. When a customer becomes an employee, which record becomes authoritative? Which permissions change? Are stronger authentication requirements applied to the right identity? When employment ends, what happens to the customer account, its old role, its sessions and the access that may have accumulated around it?
There is no single answer that fits every organisation. Separate customer and workforce systems can be a valid architecture, but the handoff between them must be deliberate. Mapping, provisioning, deprovisioning, tenant membership and policy changes need defined ownership—not assumptions that a connector will keep every fact in sync forever.
For B2B SaaS, the bridge also includes tenant boundaries. A tenant may configure SSO and manage its own members, but the service still needs to know which tenant owns an identity, which policies apply and who is allowed to administer that tenant. The same email address or display name is not, by itself, a safe basis for transferring authority.
3. One house, one foundation—and separate doors
The third illustration proposes a different organising principle: one identity model with distinct rules for the identities that use it. Customers, employees, administrators and agents do not have the same needs. They should not automatically receive the same authenticators, lifecycle permissions, session limits, network rules or access scopes. The shared foundation provides a consistent place to apply and record those differences.
One foundation does not mean one universal policy. It means that differences are explicit and managed instead of being scattered across loosely connected systems.
Different identities
Customer, employee, administrator, service and machine identities have clear classifications and attributes suited to their roles.
Different rules
Authentication assurance, network restrictions, sessions, lifecycle permissions and resource access can vary by identity class and context.
Connected operations
Provisioning, access requests, reviews, expiry, support and audit events relate to the same identity and its resources.
What a shared foundation needs to get right
The metaphor is useful only if it leads to testable engineering decisions. During an architecture review, ask:
- Can every identity be classified clearly? Make customer, employee, administrator, service and machine identities distinguishable without relying on conventions hidden in application code.
- Does access follow the lifecycle? Define what changes at onboarding, role changes, transfer, suspension and departure—and which resource assignments should expire or be revoked.
- Are sensitive operations protected by their own preconditions? Signup, authentication, credential enrollment, recovery and privileged actions should not be interchangeable paths.
- Can support help without becoming a bypass? Recovery and impersonation workflows should have strict limits, clear approvals where appropriate and records the account owner or investigator can understand.
- Can you reconstruct the decision? An audit trail should help answer who or what initiated an action, which identity and resource were involved, what context applied, and why the transition was allowed.
- What happens when an integration is late or wrong? Test retries, stale directory data, partial provisioning, connector outages and failed deprovisioning. Fallback paths need explicit controls too.
How WebFrolic approaches the identity house
WebFrolic's supplied design material describes a shared identity model for customers, employees and administrators, with separate dashboards and configurable rules by identity class. It also describes server-side extended state for identity flows, transaction-based orchestration, tenant-level controls, configurable authenticator assurance, network restrictions, service and test user types, access request and review workflows, support desks and audit capture.
Those elements are intended to address the seams shown in the first two illustrations: state that is hard to reconstruct, privileges that outlive the task or person, and operational workflows that drift away from the identity record. Actual protection still depends on correct configuration, implementation and operation; the diagram is an architecture explanation, not a claim that configuration alone guarantees security.
Use the house as an architecture test. For every new identity feature, ask whether it strengthens the foundation, creates another floor with its own rules, or adds a bridge that someone must maintain.
Frequently asked questions
Does one identity foundation mean replacing every existing vendor?
No. The goal is a coherent identity model and explicit boundaries. Some organisations will retain specialist systems. The important point is to define authority, integration failure behaviour, lifecycle ownership and how audit evidence follows the action across the system.
Should customers and employees have identical security settings?
No. A shared model should make policy differences easier to express, not erase them. Employees, customers, administrators and non-human identities may need different assurance requirements, network boundaries, session limits and lifecycle rules.
Where should an organisation start?
Map the identity journeys that cross system boundaries first: customer-to-employee changes, tenant SSO onboarding, employee offboarding, service-account ownership and account recovery. Identify who owns each transition and what evidence proves it completed.
Take it into your next review
Sketch your own identity house
- List the systems that authenticate, provision, approve, audit and support identities.
- Draw the bridges between them: connectors, shared credentials, sync jobs and manual handoffs.
- Mark where one person or service can hold multiple records or roles.
- Choose one fragile bridge and define a test for the failure case.