This blog post looks at the terms identity and account as well as other related notions. The various concepts and their interrelationships are particularly important in Identity and Access Management (IAM) in order to develop a valid model and corresponding architectures.
Firstly, a picture of entities and identities will be created in order to then outline their technical representation. At the end of this post, challenges that one faces in a functioning and established Identity and Access Management will be worked out.

About Entities and Identities

The basis for a functioning IAM is the concept of the relationship between entities and identities. They help to talk more precisely about the real world and its technical representation as well as to convey the differences.

An entity is something that exists in the real world and forms a distinguishable unit. In addition to tangible items, this also includes non-physical forms such as organisations.

An identity is the abstract concept of sameness that can be applied to real-world entities. An entity can have several identities and, conversely, an identity can refer to several entities. An identity is therefore a selection of facts about one or more entities. The identity therefore expresses the sameness of this selection.

The above outlined definitions become clearer through examples. A person P is an entity, as is company C. Person P is an employee of company C. The role of the employee in company C is an identity of person P.

From the point of view of company C, there is an identity employee of company C. All employees and therefore also person P have this identity due to the fact that they are employees of company C.

As a further example, person P has a private telephone number T. In a telephone directory, the telephone number T is the identity of person P.

Theoretically speaking, it is possible for an identity to combine all the facts of an entity. This is not realistic in practice and therefore identities are often to be understood as a role that an entity takes on. In principle, however, a distinction can be made between theoretically existing holistic identities and partial identities. In practice, especially in IT systems, the term identity is used to refer to partial identities.

Accessing Systems

As the name Identity and Access Management suggests, part of the discipline is the implementation and management of access mechanisms. The terms accounts and credentials are often used in this context. Their relationship is described below.

An account is an entry in a register that can be used to gain access to one or more systems.

Credentials are linked to an account. The credentials are used to prove that one has control over that account.

The telephone book example mentioned at the beginning can be used for this illustrating the terms. Person P receives a new telephone number T'. So in order for person P to be able to change their entry on the telephone directory website, person P has an account A. This account A is provided with a user name and password as credential C. Person P knows these credentials C and can log in there and change their own telephone number to T'.

Representing and Storing an Identity

To represent an identity in systems, the relevant data of an entity is mapped in a data set to form an identity. The data are called attributes of an identity and are elements such as the first name, surname or telephone number. The data set resulting from this record is also called an object.

An object can fulfil the property of an account. This is particularly the case in the field of Identity and Access Management. In fact, several accounts can be assigned to one identity. For example, an employee M is managed in an HR system and has an identity there, which is required for payroll accounting, for example. From the identity managed there, employee M has access to an ERP system E and a timesheet software T. This employee M has an account for each software. The accounts are objects that can be used for access and therefore contain additionally credentials (see definitions above).

The following conceptual relationship therefore exists: object ⊇ identity ⊇ account.
Identities are objects in an (IT) system and some of these identities are also accounts. Note, however, that from a technical stand point objects represent identities and accounts are objects (see picture). 

In practice, accounts are therefore accesses to systems whose attributes can be very minimal. Identities, on the other hand, comprise more attributes in order to describe an entity more comprehensively and, if necessary, to identify roles and applicable policies. Both the CEO of a company and an IT administrator have access to systems, but their role attributes for their identity can be used to differentiate who should be sent alerts from a monitoring system.

Challenges within the Discipline

Anyone who wants to create a model for entities, identities and associated accounts will quickly encounter a number of challenges. Some of the most frequently overlooked ones will be discussed at the end of this blog post.

• Low-identity Accounts: An account can include so few attributes that using the account reveals little or no information about an identity. This is particularly the case if the account is only a shell for storing credentials. This means that no attributes are available to link them to other data records and identify the entity behind the account. This is particularly critical as it is not possible to trace which entity is behind an account.
• Entity Identity Relationship Mapping: It is a major challenge to assign entities to identities, but also to assign identities to each other to the same entity. The assignment is often made more difficult by missing, unique attributes or attributes that are not selected uniformly. This is a particular problem with identity-to-identity mapping. The set of selected attributes may also not be sufficient to clearly assign an identity to an entity. For example, the name and place of birth of an entity are mapped. However, it can happen that two entities have the same name and were born in the same place. This creates a conflict in the assignment.
• Technical or Service Accounts: Accounts for the access of systems to interfaces of another system are often overlooked. These systems also have an identity and it should be assignable to the corresponding accounts.
• Identity sprawl: As previously established, an entity necessarily has several identities. However, it often happens that there is an accumulation of identities within an organisation because there is no leading source. This means that partial identities are created in several systems, e.g. to carry out payroll accounting or create an organisation chart. This should be avoided as far as possible and such activities fall under the discipline of Identity Governance. Typically, a leading register must be identified and the identity held there. If additional identities are required for system architecture reasons, these must be managed automatically from the leading source.
• Account Sprawl: Similar to the identity sprawl, accounts to be maintained are created in various IT systems of an organisation. As with identity sprawl, this should be avoided and can often be limited by simple measures such as Identity Federation.

In conclusion, it should be noted that the relationships described above only provide a possible model. Other works can be found in [1, 2], for example.

[1] Clarke, R. (2021). A Platform for a Pragmatic Metatheoretic Model for Information Systems Practice and Research.
[2] Clarke, R. (2009, June). A sufficiently rich model of (id) entity, authentication and authorisation. In The 2nd Multidisciplinary Workshop on Identity in the Information Society, LSE (Vol. 5).