Of Entities, Identities and User Accounts (AKA: I need to know who IAM)

Image by Ben Sweet <https://unsplash.com/@benjaminsweet> via <https://unsplash.com/photos/2LowviVHZ-E>

I often see that the concepts of Entity, Identity and Form of Identity are assumed as understood by all parties, and yet rarely with the same definition for all. These are not specific to the realm of IAM, with the first two being universal and the latter being simply derived from their physical-world counterparts. The problem is, as we will see, that not having a clear understanding of what they mean and their importance, will lead us to make design mistakes which will have an impact in our security and governance.

Let's go step by step and try to understand each of these terms, in the physical world, to map them later to the digital one.

Entity

An Entity is defined as "something that exists independently, not as part of a whole". This is the foremost node in the identity chain. John Smith is an entity (a car is also an entity, as is a service or an application, in the digital world, but let's stay with John as a simpler example, for now). John can't be more than one entity, no matter what.

Identity

An Identity is something that uniquely singles out (identifies) an entity. It is inherent to the entity. In fact it is inherent to a single entity (that is, it identifies only one). In the case of John Smith, his Identity is his name, social security number, etc. Yes, there are other John Smiths, but they are other John Smiths. The Government (or whichever the Identity Provider is) has one Identity for only this John Smith. 

Can John have more than one Identity? Yes, he can. An Identity is not a document or a database record. It's a concept. If John goes to his local library and they do not require a Proof-of-Identity for him to get a Library Card, he could provide a fake name and set up a new Identity right then and there. Or he could simply think of himself as J the Magnificent when he's daydreaming on the bus. Or he could have a different Identity for his internet presence. Whenever John starts using an alias with the intent of making it untraceable to his already existing Identity, that is indeed a new Identity. It does not really matter if the Library only collects his first and last name, making it too difficult to link it to his Government-Issued Identity. He's still operating under the same Identity, even if this form is not the most robust.

Of course, for the same Identity Provider, John should never have more than one Identity (unless he's a spy, a criminal, a witness in some sort of protection program, or he's trying to trick the Library in order to check out more books than he's allowed). If the same entity is being linked to more than one Identity, we will be bypassing the very purpose of having an Identity at all.

Form-of-Identity

What John will definitely have is multiple Forms-of-Identity. His passport, his National Identification Document, his Driving License, his Library Card... They all relate to the same Identity, though. If the Police came to the library and asked "Has John Smith checked out any books lately?" the Librarian would be able to provide an answer (even if this is: "Well I have 3 John Smiths, take your pick."). Forms-of-Identity are nothing more than actual manifestations of that Identity, issued for different purposes.

Meanwhile, in the Digital World...

While Entity and Identity are universal concepts that are not bound to the physical or digital worlds, forms-of-identity definitely have their digital counterparts. We know them as User Accounts. Linked to the same Identity, a User Account is simply the document that the specific Business or Organization requires in order to know who John is and provide him some services. The process of Authentication (proving that the document is held by its rightful owner) is analogous to showing our Library Card to the Librarian.

With this in mind, let's note that, when an organization uses an Identity Management solution to create the account of a new employee, they are not creating an Identity. They are registering an already existing Identity (belonging to the person -the entity- itself) in the repository that they will use to know who is an employee. And most likely, along the process, they will also create a User Account as the Form-of-Identity that the new joiner will use to access the organization's tools, network and domain in general. In fact, I bet that there are very few organizations in which that single User Account will be enough. Most of them have a high number of satellite systems which will require additional User Accounts to be created for the same Identity -for the same person.

Ok, so why is this so important?

Now that we understand all the different concepts and the Entity-Identity-Account hierarchy, let's quickly have a look at the problems that misunderstandings could introduce.

Let's say there is a law in John's country stating that nobody can perceive government subsidies if they make more than $50,000/year. John makes way more than that. However, this rule is not enforced at Identity-level, but for the identity document. Which means that all John has to do is submit their tax declaration under their driving license and claim subsidies under their Passport. Ridiculous, right? That's because those restrictions are typically enforced at the proper level (Identity).

However, in the Digital world it is quite frequent to see that Authorization is done at User Account level, instead of at the Identity level. This means that, for the purposes of Access Management, "John.Smith" and "System.Administrator.John.Smith" are actually considered as two different Identities, and therefore any type of Identity-based resatrictions cannot be enforced. By not configuring Authorization at the Identity level, "System.Administrator.John.Smith" could submit an expense claim and "John.Smith" could approve it, and the system would not see anything wrong with that.

The parallelism with the physical world remains. Regulatory enforcement cannot be done at User Account level if you are actually trying to prevent Identities from breaking the rules. Authorization in particular needs to happen at Identity level, even if the system will later require the user to present a specific document: that is, to log in with a specific User Account (of which the user might have more than one indeed).

Comments

Popular posts from this blog

Understanding IAM Governance (AKA: How we monitor, control and decide)

How to establish a trust anchor (AKA: Digital onboarding of remote employees)