Vendor-neutral identity and access management guides for authentication, authorization, federation, least privilege, privileged access, workload identity, secrets, access reviews, and zero trust.
Identity and access management answers a blunt operational question: who or what is allowed to do which action, against which resource, under which conditions, and with what evidence? The answer is never only a login screen and never only a permission list. Strong IAM joins identity proof, authorization logic, credential lifetime, governance, monitoring, and removal of stale access.
This guide is vendor-neutral. AWS IAM, Microsoft Entra ID, Google Cloud IAM, Kubernetes RBAC, Linux accounts, SaaS identity providers, and enterprise privileged access tools use different names, but the durable model is shared: authenticate the principal, issue or evaluate a credential, authorize a request, record evidence, and keep access aligned with real need.
| Concept | The question it answers |
|---|---|
| Identity | Which human, service, device, or workload is making the request? |
| Authentication | How does the system prove the requester is who or what it claims to be? |
| Authorization | What is the authenticated principal allowed to do? |
| Federation | Which trusted identity system is allowed to authenticate users for another system? |
| Delegation | How can one app or service act with scoped permission without receiving a password? |
| Least privilege | What is the smallest practical permission set for the task? |
| Privileged access | Which elevated actions require stronger control, approval, logging, or time limits? |
| Workload identity | How do applications and automation prove identity without embedded long-term secrets? |
| Access lifecycle | How are permissions requested, granted, reviewed, changed, and removed? |
| Zero trust | How are identity, device, context, policy, and telemetry evaluated continuously? |
Most bad IAM designs blur these distinctions. MFA strengthens authentication, but it does not decide authorization. SSO reduces local account sprawl, but it does not prove least privilege. A role can remove embedded credentials, but a broad role can still be dangerous.
flowchart LR
P["Principal"] --> A["Authenticate"]
A --> C["Credential or session"]
C --> Z["Authorize request"]
Z --> R["Resource action"]
Z --> L["Log decision and context"]
Use this path when diagnosing access questions. If the principal cannot obtain a session, the failure is authentication or federation. If the session exists but the action fails, inspect authorization policy, resource policy, scope, conditions, and guardrails. If the action succeeds but cannot be explained later, the missing control is evidence and governance.
| Read | Use it to answer |
|---|---|
| Authentication vs Authorization | Is the problem login, proof, permission, or policy evaluation? |
| Federation and Single Sign-On | When should identity be centralized rather than copied into every system? |
| OAuth, OIDC, and SAML | Which protocol pattern fits sign-in, token claims, or delegated access? |
| RBAC, ABAC, and Policy Models | How do roles, attributes, conditions, and resource policies combine? |
| Least Privilege | How do you reduce access without breaking necessary work? |
| Privileged Access Management | How should administrator and emergency access be controlled? |
| Workload Identity | How do services and automation authenticate without long-term keys? |
| Secrets, Keys, and Credentials | What should be stored, rotated, scoped, and protected differently? |
| Access Reviews and Lifecycle | How do joiner, mover, leaver, and periodic review processes prevent drift? |
| Zero Trust Access | How do identity, device, context, and continuous evaluation shape modern access? |
| Identity and Access Management Cheat Sheet | How do the major decisions fit together during exam or design review? |
| Architecture role | AWS examples | Microsoft examples | Google Cloud examples | Platform-neutral examples |
|---|---|---|---|---|
| Workforce identity | IAM Identity Center, external IdP federation | Microsoft Entra ID | Cloud Identity, workforce identity federation | identity provider, directory, SSO |
| Workload identity | IAM roles, STS, service-linked roles | managed identities, workload identity federation | service accounts, workload identity federation | service identity, short-lived token |
| Authorization policy | IAM identity policies, resource policies, permission boundaries, SCPs | Azure RBAC, role assignments, conditional access | IAM allow policies, deny policies, org policies | ACL, RBAC, ABAC, policy engine |
| Privileged access | break-glass root controls, IAM Access Analyzer, CloudTrail evidence | Privileged Identity Management, conditional access | privileged role workflows, audit logs | PAM, JIT access, session recording |
| Secret storage | Secrets Manager, Parameter Store, KMS | Key Vault, managed HSM | Secret Manager, Cloud KMS | vault, HSM, key-management system |
| Lifecycle governance | IAM Identity Center assignments, Organizations guardrails | Entra lifecycle workflows, access reviews | IAM recommender, policy intelligence | joiner-mover-leaver, certification campaign |
The table is an orientation, not an equivalence claim. Always verify whether the platform evaluates identity policy, resource policy, organization guardrail, network condition, encryption key policy, and session constraint independently.
Do not solve an IAM question by adding another allow statement first. Identify the principal, session path, permission boundary, resource boundary, and evidence trail. The secure answer is often the one that changes the access model: federation instead of copied users, roles instead of keys, temporary privilege instead of permanent admin, policy conditions instead of broad resource access, and reviews instead of silent permission drift.
Authoritative background references include NIST SP 800-63, NIST SP 800-207, OAuth 2.0 RFC 6749, OpenID Connect Core, and the OASIS SAML 2.0 technical overview.