Identity as Architecture: Designing Access for Ownership, Audit, and Revocation
Login Is the Easy Part
Every enterprise I walk into has solved authentication. Very few have solved what happens after it.
A recently published architecture case study from regulated financial services makes this painfully concrete. The team had wired up SSO, validated tokens at the edge, and shipped features – until scale turned “who can touch this resource?” into an audit question that their schema simply could not answer. Flat RBAC buckled under questions about ownership and validity; roughly eighty thousand real people owned service accounts; attestation, rotation, and vaulting lived in three disconnected tools; revocations travelled over an event stream. What makes it worth reading isn’t the stack. It’s the reasoning.
Identity is a data-modelling decision, not a vendor decision
The sharpest test in that piece deserves to be pinned to every CTO’s wall: could you answer “who had access to this system on 14 March?” from your data model alone, without grepping logs across five tools? I have sat through enough review meetings in Guwahati and Delhi to know how many teams quietly fail that one. A security review can catch a missing check; it cannot retrofit a schema that was never built to remember. Record grants, revocations, and attestations as timestamped events with an actor from the first release – that habit costs almost nothing early and is nearly impossible to buy later.
Model the constraint where the query runs
The team’s shift from role tables to relationship traversal is defensible, but only because their questions were genuinely relational: who owns this, is this still valid, what does this person actually control. Note their honesty about the trade-offs – an extra datastore to operate, and a badly shaped graph being slower than the join it replaced. My rule: a validity check that lives in every query is a bug factory. Put expiry inside the traversal so no consumer can skip it. Architecture is where constraints become unavoidable.
Governance is a retention problem wearing a security costume
Eighty thousand owners means the dominant risk is human: the account whose owner changed teams, and the credential nobody is watching. Even more telling than the graph work is that folding three tools into one workflow cut time-to-revoke from roughly three days to under one. That isn’t a database win – it’s friction removal. A lot of what we label technical debt in identity is process debt charged to the human.
And on eventual consistency, the discipline is honesty: measure the worst case, cap it with a maximum cache age, and state the number to your security team before they invent one for you. When integrating a vault your team doesn’t govern, fail closed. “We sent the request” is not success.
The Bharat bridge
India’s Digital Public Infrastructure is this same essay written at national scale – an identity layer, consent artifacts with timestamps, attestation flows. The lesson for state e-governance and MSMEs isn’t to buy a bank’s architecture for a portal. The threshold is organisational, not technical. Start with the event log, not the graph store.
Takeaways
- Design identity into the schema; audits reward memory, not reconstruction.
- Move to graph-shaped data only when your questions become ownership-and-validity, and expect to earn the gains through modelling discipline.
- Measure revocation staleness and publish the bound.
- Treat owner attrition as your primary control failure.
Login is a checkbox. Accountability is the architecture.