Identiy, Users and Access: The holey trinity

 

Identity, Users and Access: The holey trinity

For some time I have been meaning to capture a snapshot of some of the key design considerations for the identity and account structure which emerged from quite a few years of requirements spanning Ad-tech, dating and multi account systems built across multiple startups.

The reasoning for sharing this model is in the hope that some of the lessons can be useful for others faced with similar challenges. If nothing else the model, as an emergent real world solution has some quirks not common in many or all public solutions in this space.

Requirements at scale of multiple companies

• In the ad tech space there is an interesting precedent designed to protect the privacy of users. Publishers and advertisers each see a different 'user id'. This is the ID that is stored in the impression and click logs which drive the entire ad industry. One of the startups explicitly needed support for the concept of scoped anonymised user identity as this was an artefact of the underlying data. We actually scoped this up to a higher level requirement for all systems and it worked nicely to avoid ever exposing the internal ID of a user.

   
• Separation of personal, an identity and user. This allows personally identifiable information to be separated from a 'user'. The concept of a user is very overloaded and is usually an account. In most real world systems you see there is a need to be able to have multiple people log in to the same account. This necessitates separation of the identity from the user[name].
• Users will probably want to log in with lots of different IDP and other sources. It's worth noting too that it's helpful to be able to have multiple grants stored for the same user.
• It's the identity, not the person or the username to which logic needs to be applied.
• At the time of writing our access system used explicit scoped grants to gift access. These scopes were effectively paths of entities. The paths for a user access were consistently named also with our tasks and other frameworks. It would have been nice to revisit this and re-scope access to identity with hindsight.
• Person Name was of particular interest as it's interesting to be able to store alias easily. Notably most systems aren't built with this up front. It is a very common use case however in production systems.
  

 

Takeaways 

The model evolved over time and as such went through a number of iterations. There are a few quirks that warrant further attention. User access was one such quirt, arguably it should be associated with the identity rather than the user concept. It ended up living in user because at the time of creation, identity and access modules were in separate packages. Access should have been separated into another module.

Looking back another thing that seemed odd is that we didn't have even a group concept. The reason for this is that the 'thing' would often be a group. The access did have a collection of types of grant which were originally based on unix style read / write / x bits. These concepts expanded over time to contain about 7 different types of permission however they didn't explode out of control.