Understanding Identity and Roles in IAM

A common point of confusion in Identity and Access Management (IAM) is the difference between identity, identifiers, and roles. It is easy to assume a role is just another word for identifier, something that "identifies" a user. That assumption turns out to be wrong, and untangling it reveals a lot about how real IAM systems are structured.

What Is an Identity?

An identity is a digital representation of a person, application, device, or service within a system. It is the full collection of information that uniquely describes an entity, essentially a digital profile.

An identity is made up of attributes. An employee identity, for example, might look like this:

Identity
--------
Employee ID : EMP 10025
Username    : sathsara
Name        : Sadeesha Kumbukage
Email       : sathsara@company.com
Department  : Engineering
Role        : Software Engineer
Manager     : John
Status      : Active

These fields are called identity attributes, and together they answer the question every IAM system starts with: who is this?

Identity Is Not Authentication, and Authentication Is Not Authorization

These three terms get lumped together often (covered in more depth in the earlier post on IAM basics), so it helps to separate them with a simple example.

Identity: "I am Sadeesha." The system simply knows there is an employee called Sadeesha.

Authentication: "Prove you are Sadeesha." This is done with a password, fingerprint, face scan, security key, or OTP.

Authorization: "Now that the system knows you are Sadeesha, what are you allowed to do?" Reading HR documents might be allowed, deleting payroll might not, and approving leave might be allowed.

Identity Is Not Just About People

IAM is not only concerned with human users. Several kinds of entities need an identity.

Machine identities let servers trust each other. Application identities let apps authenticate through mechanisms like OAuth. Service identities let microservices, such as an order service and a payment service, recognize one another. Device identities let phones, laptops, and IoT devices prove what they are before being granted access.

Identity vs Identifier

An identifier is a single value that uniquely points to an identity, such as a username, an email, an employee ID, or a UUID. For example, Username = sathsara is an identifier.

An identity, on the other hand, is the complete representation: the identifier plus all of its attributes.

Username   : sathsara
Email      : sathsara@company.com
Role       : Admin
Department : IT
Status     : Active

So the rule of thumb is simple:

Identity equals Identifier plus Attributes.

The Identity Lifecycle

An identity is not static. It changes as a person's situation changes within an organization, and managing that change is a core responsibility of any IAM system.

A Simple Analogy: The Passport

A passport is a useful way to make this concrete.

A passport contains a passport number, which is the identifier, along with a name, date of birth, nationality, and photo, which together form the identity. Showing the passport at immigration is authentication. The visa inside, which determines what the holder is allowed to do in that country, is authorization.

Are Roles Identities?

This is a common trap: assuming a role is an identifier for an identity. It is not. A role is an attribute or assignment associated with an identity, not something that identifies a person.

A role is best understood as a set of permissions that can be assigned to an identity.

Role: Software Engineer

Permissions:
    Read Repository
    Create Build
    Deploy Development

The role does not represent a person. It represents a bundle of permissions that gets attached to an identity.

So Why Do People Sometimes Call Roles Identities?

Because in certain IAM systems, a role can act as a security principal. A principal is anything that can request access to a resource, and that includes users, services, applications, devices, and in some cases, roles themselves.

A role becomes a principal when something assumes that role. AWS IAM is a good example of this in practice. An EC2 instance should not carry permanent credentials, so instead it assumes an IAM role temporarily.

Here the EC2 instance is the identity, and the IAM role behaves like a temporary identity with permissions rather than a permanent one.

The same idea applies to a developer assuming an administrative role for a session.

During that session, the system effectively treats Alice as the role she has assumed.

Identity, Role, and Permission Together

A useful mental model here is a company badge. The identity is the employee, for example Sadeesha with employee ID 10025. The role is the job position, such as Software Engineer. The permission is the set of allowed actions, such as reading a Git repository, deploying an application, and viewing logs.

Why Roles Exist in the First Place

Imagine a company with ten thousand employees. Without roles, every single person would need permissions assigned to them individually.

Sadeesha
    read_database
    deploy_code
    create_user

John
    read_database
    deploy_code
    create_user

Mary
    read_database
    deploy_code
    create_user

That quickly becomes impossible to manage. With roles, the permission set is defined once and assigned to everyone who needs it.

Software Engineer Role

Permissions:
    read_database
    deploy_code

Sadeesha to Software Engineer
John to Software Engineer
Mary to Software Engineer

If the permissions for that role change later, for example by adding access_logs, every person holding that role receives the update automatically. This pattern is generally known as Role Based Access Control, or RBAC.

Where the Confusion Usually Comes From

Part of the confusion is that roles often have their own identifiers too. In AWS IAM, a role might look like this:

Role:
    arn:aws:iam::123456789:role/AdminRole

And a user might look like this:

User:
    arn:aws:iam::123456789:user/Sadeesha

Both have identifiers, but one identifies a role and the other identifies a user. They are separate identities in the system, not the same concept wearing two names.

A More Complete Picture

In an enterprise IAM setup, roles are often assigned automatically based on identity attributes.

For example, if the department attribute equals Finance, the system might automatically assign a Finance Analyst role. This attribute driven assignment is one of the things that makes large scale IAM systems manageable.

Key Takeaways

Identity answers who is this. Role answers what type of access should this identity have. Permission answers what actions can this identity actually perform.

The next concept worth digging into is the idea of a Principal, since in IAM the word principal is often used in places where identity might be expected, especially in AWS, OAuth, and access control policies.