Identity and Access Management
Identity and access management (IAM) coordinates identity records, sign-in, permissions, account lifecycle, and activity evidence. Authentication asks who is making a request. Authorization asks what that identity may do. Accounting records what an account did. These three responsibilities are often called AAA. None replaces the others. Source: IAM Ecosystem Explained (01:39-02:54).
Responsibility Map
The video presents an architecture of responsibilities, not a required product stack. One platform can supply several capabilities; applications still need to enforce their own permissions. Source: IAM Ecosystem Explained (25:20-27:09).
| Responsibility | Role in the Architecture | Connected Concept |
|---|---|---|
| HR and directories | Employment status, user records, attributes, and groups | Identity Lifecycle and SCIM |
| Identity provider (IdP) | Authenticate users and provide trusted sign-in information | SSO and Federation |
| Provisioning | Create, update, and deactivate application accounts | SCIM |
| Applications | Enforce the permissions required for each action | Kubernetes RBAC as a concrete implementation |
| Governance | Decide appropriate access, approvals, conflicts, and reviews | IGA |
| Privileged access | Protect powerful accounts, credentials, and sessions | PAM |
| Monitoring | Correlate sign-ins and significant actions for investigation | Context and Risk |
Active Directory illustrates a directory service; Entra ID and Okta illustrate broader identity platforms. These categories overlap, but storing an identity is different from authenticating it or deciding its permissions. Source: IAM Ecosystem Explained (02:54-04:17).
Roles, Attributes, and Lifecycle
Least privilege grants only the access needed for the work. Role-based access control (RBAC) groups permissions by responsibility. Attribute-based access control (ABAC) adds conditions using user, resource, or context information, such as an assigned country or a managed device. The video combines these models; it does not claim that a basic role alone enforces contextual rules. Source: IAM Ecosystem Explained (06:47-09:08).
Sarah’s hypothetical departure shows why successful sign-in controls are insufficient. Disabling her mailbox does not reach a forgotten local account. The alternative ending checks application disablement, sessions, and supported token revocation. IAM must follow changes in access over time, not just the login event. Source: IAM Ecosystem Explained (00:24-01:39; 15:40-16:36; 27:09-27:53).
The same responsibility map extends to customer identities, external partners, and Machine Identities. Their populations and access needs differ; an employee HR workflow is not the only identity lifecycle. Source: IAM Ecosystem Explained (23:08-25:20).