Identity & Access Management (IAM)

Who gets a badge, and which doors does that badge open? Every person and every service needs a verified identity before it’s trusted with anything.

At a glance

• What it is: a centralized system for authenticating identities (people and services) and authorizing what each identity can access, instead of every application inventing its own login and permissions.
• Why it matters: when every app manages its own accounts and permissions, access becomes inconsistent, hard to audit, and slow to revoke — a departing employee can leave forgotten accounts active for months.
• For developers: never build your own login form or password store — integrate with the organization’s identity provider (SSO/OIDC/SAML) and ask it “who is this, and what are they allowed to do?”
• When to use it: for every system that has more than one user or needs to trust another service — which is nearly all of them.
• When not to use it: a fully local, single-user developer tool with no sensitive data may skip centralized IAM, but anything touching production or shared data should not.
• Prerequisites: none — this is usually the first security architecture control an organization puts in place.

Mental model

flowchart LR
    U[User or service] --> IDP[Identity provider]
    IDP -- "MFA + credentials verified" --> T[Token issued]
    T --> APP[Application]
    APP -- "Is this token valid? What roles does it carry?" --> IDP
    APP --> D{Authorized for this action?}
    D -- No --> R[Reject]
    D -- Yes --> ALLOW[Access granted]

Step-by-step walkthrough

1. Register the application with the organization’s identity provider (IdP) instead of building local login.
2. Require multi-factor authentication (MFA) for any account with access to sensitive systems, not just passwords.
3. Model authorization with roles or attributes (RBAC/ABAC) rather than granting access to named individuals one at a time.
4. Grant access through group/role membership tied to a person’s job function, so access changes automatically when their role changes.
5. Review access periodically (access recertification) and revoke immediately on offboarding — don’t rely on accounts quietly expiring.

Worked example

A support engineer’s password is phished. Because the admin console has no MFA and trusts anyone already on the corporate VPN, the attacker logs in with just the stolen password and starts pivoting toward other internal tools.

• Input: a single compromised password, no second factor required, and an admin console that implicitly trusts VPN-connected traffic.
• Process: the team enrolls the admin console with the corporate identity provider, requires MFA for all administrative accounts, and moves to role-based access so the support engineer’s account only ever had access to the support queue — not billing or infrastructure tooling.
• Output: a phished password alone is no longer enough to log in, and even if MFA were somehow bypassed, the compromised account’s blast radius is limited to what a support role actually needs.

[Authorize(Policy = "RequireSupportRole")]
[HttpGet("tickets/{id}")]
public IActionResult GetTicket(string id) => Ok(_tickets.Get(id)); // never billing or infra data

The admin console authenticates against Microsoft Entra ID, which enforces Conditional Access requiring MFA for administrative sign-in, and the support engineer’s role maps to an Entra ID group with only support-queue permissions.

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(supportFunctionApp.id, 'Key Vault Secrets User')
  scope: kv
  properties: {
    principalId: supportFunctionApp.identity.principalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6')
    principalType: 'ServicePrincipal'
  }
}

This role is granted to the support tool’s Function App system-assigned managed identity, not a shared key or a named person — revoking access on offboarding is deleting this one role assignment, the same principle as the group-membership revocation described above.

Common use cases

Use case	When to use	Notes
New internal tool needs a login	Before first release	Integrate with the org’s SSO/IdP instead of building local accounts
Employee changes teams	At the moment of the role change	Update group/role membership; access should follow the role, not the person
Employee leaves the company	Immediately on offboarding	Revoke IdP access centrally so it cascades to every connected app, rather than remembering each one
Service needs to call another service	At integration design time	Use service identities (e.g. workload identity, service principals) — not a shared static API key

Advanced details

• RBAC vs. ABAC: role-based access control assigns permissions to named roles (e.g. “billing-admin”); attribute-based access control evaluates rules against attributes (department, sensitivity, location) for more fine-grained decisions.
• Federation: SSO protocols like OIDC and SAML let one identity provider be trusted by many applications, so a user authenticates once and carries that identity everywhere.
• Standing vs. just-in-time access: instead of permanent admin rights, just-in-time access grants elevated permissions only for the duration of an approved task, then revokes them automatically.

Quick reference

Term	Meaning
Authentication	Confirming who is making the request
Authorization	Confirming what an authenticated identity is allowed to do
MFA	Multi-factor authentication — a second proof of identity beyond a password
RBAC / ABAC	Role-based / attribute-based access control models
SSO	Single sign-on — one login trusted across multiple applications
Just-in-time access	Temporary, approved elevation of privilege for a specific task

Troubleshooting

Symptom	Likely cause	Fix
A stolen password alone grants access	No MFA enforced	Require a second factor for all accounts, especially admin ones
Access lingers after someone changes roles or leaves	Access is granted per-person instead of via group/role membership	Move to role-based access tied to the IdP so revoking one thing cascades everywhere
Every app has its own login and password rules	No central identity provider	Integrate all apps with a single SSO/IdP

Check your understanding

• What’s the difference between authentication and authorization?
• Why is granting access through a role or group generally safer than granting it to a named individual directly?

Related pages

Part of Introduction to Security Architecture. See also Zero Trust & Network Segmentation, Incident Response & Security Operations, Security by Design (Application-Level), and the Glossary.