Identity and Access Management (IAM): Definition and Examples

What is Identity and Access Management (IAM)?

Identity and Access Management (IAM) is the set of policies, processes and tools that decide who can sign in to a system and what each identity may do once inside. An identity can be a person, a service or a device. IAM answers three questions: who are you, what are you allowed to do, and what did you do.

How IAM works

Every IAM setup combines three pillars. They run in order: a request is authenticated, then authorized, and the outcome is recorded.

Single sign-on sits on top: one login session unlocks several applications, usually through a protocol such as SAML or OpenID Connect, so access can be removed in one place when someone leaves.

Access control models

• RBAC (role-based): permissions attach to roles such as "viewer" or "billing manager", and people get roles. The most common model and the easiest to review.
• ABAC (attribute-based): a rule compares attributes of the user, the resource and the context, for example "allow if user.department equals resource.department". Finer grained, harder to audit.
• ACL (access control list): each resource carries its own list of who may do what. Fine for files and small systems, awkward at scale.

Example: a CI job that pushes a container image

A pipeline needs to push an image to one registry repository. A weak setup gives it a shared admin key that lives in a build variable forever. A sound IAM setup gives the job its own service identity with a role that allows only "push to this repository", issues credentials that expire after the job, and logs every call. If the pipeline is retired, the identity is deleted and nothing else changes.

Common IAM mistakes

• Over-privileged accounts. Admin rights granted "just for now" and never removed.
• Shared credentials. Several people or services on one login, so no log line can be traced to anyone.
• Long-lived secrets in code. Access keys committed to git or pasted into tickets. Prefer short-lived tokens.
• Stale accounts. Former employees, old contractors and retired services that still hold access.
• No multi-factor authentication on admin accounts. One stolen password becomes a full breach.
• No access reviews. Permissions pile up for years because nobody checks them.

IAM, API security and performance testing

IAM is enforced at the API: every call carries a token or key that your gateway checks against roles and policies. That is the topic of API security, and it is why a healthy IAM setup also has to survive real traffic. Token issuers rate limit, tokens expire in the middle of a long test, and a refresh adds latency of its own. The guide on performance testing APIs with OAuth2 walks through those effects.

LoadFocus is not an identity provider, so you keep your own IAM. What it gives you is the traffic side: load testing to see how your login and token endpoints behave under load, and API monitoring to watch protected endpoints continuously.

FAQ: IAM

What is the difference between authentication and authorization?

Authentication proves who you are, for example with a password and a second factor. Authorization decides what you may do after that, using roles or policies. A system authenticates first, then authorizes each action.

Is RBAC enough?

For most teams, yes. Start with a small set of roles and review them regularly. Move to attribute-based rules only when roles multiply or when access depends on data, such as one tenant never seeing another tenant's records.

What is least privilege?

Granting an identity only the permissions it needs for its task, and nothing more. Deny by default, grant specific actions on specific resources, and the damage from a leaked credential stays small.

How is IAM different from PAM?

IAM covers every identity and every access decision. Privileged Access Management (PAM) is the subset that protects powerful accounts such as root, database admins and break-glass users, usually with vaulted credentials, session recording and time-limited access.

Should I build my own IAM or use a provider?

Use an established provider or your cloud's built-in IAM. Password storage, session handling, recovery flows and audit trails are easy to get subtly wrong, and a mistake there affects everything behind the login.