I Bet Nobody Has Ever Explained the Security (IAM) Ecosystem Like This Before

Summary

The video explains Identity and Access Management (IAM) through the example of Sarah, an employee whose access changes as she joins a company, moves between teams, and eventually leaves. The central lesson is that IAM is a connected set of processes and tools—not just a login system. Gaps between systems can leave accounts active after an employee departs.

The three A’s

IAM addresses three questions:

• Authentication: Who are you? The system verifies a person’s identity.
• Authorization: What are you allowed to do? The system grants access according to permissions.
• Accounting (auditing): What did you do? Systems record activity so it can be reviewed or investigated.

Identity records and authentication

HR systems commonly provide identity processes with core employee information, such as department and manager. Directories store user and group information. Active Directory is a directory service often used in Windows environments, while Microsoft Entra ID and Okta are identity platforms that manage access to applications and support features such as single sign-on (SSO).

Groups simplify administration by allowing shared permissions to be assigned to multiple employees.

Authentication factors include something you:

• Know, such as a password or PIN
• Have, such as a phone or security key
• Are, such as a fingerprint or face

Multifactor authentication (MFA) requires at least two different factor types. Passwords alone are vulnerable to reuse, theft, and phishing. Text-message codes and repeated login-approval prompts also have weaknesses.

Passkeys use a cryptographic key pair. The private key stays on a device or supported key manager and is not sent to the service. Because passkeys are tied to the legitimate service, they can resist phishing. Account recovery also needs strong protection; a weak reset process can undermine secure login.

Permissions and access models

Least privilege means giving people only the access they need for their work, limiting potential damage if an account is compromised.

Two common access-control models are:

• RBAC (role-based access control): Assigns permissions to roles, such as a support-agent role.
• ABAC (attribute-based access control): Evaluates attributes such as a user’s department, a resource’s country, or whether a device is company-managed. It can add contextual rules to role-based permissions.

Having an account does not automatically grant permission to everything; applications must enforce their own access rules.

SSO, federation, and tokens

Single sign-on (SSO) lets a user authenticate through a central identity provider and access connected applications without signing in separately to each one. Federation is the trusted relationship between an identity provider and an application.

Common standards and technologies include:

• SAML, often used for enterprise SSO, sends a signed assertion about the user.
• OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0. In a typical flow, an application receives an authorization code and exchanges it for tokens. An OIDC identity token is a JWT.
• JWT is a compact way to represent signed information; it is not a login protocol by itself.
• OAuth primarily enables delegated access. An application receives an access token for approved permissions rather than the user sharing a password.

Applications may maintain sessions and use access or refresh tokens. Disabling an account does not necessarily end existing sessions or deactivate separate local accounts.

Employee lifecycle and elevated access

IAM covers the joiner, mover, and leaver lifecycle: creating access, adjusting it when someone changes roles, and removing it when they leave.

SCIM provides a standard way for compatible applications to create, update, and deactivate accounts. Automation still needs verification because some applications require special integrations or manual changes. When employees move roles, organizations should grant new permissions and remove old ones. Failing to do so can cause privilege creep.

Offboarding should go beyond disabling email or the central identity. Organizations may also need to disable local application accounts, revoke tokens, and terminate active sessions.

For elevated permissions:

• Just-in-time access grants permissions temporarily, often after approval, and revokes them when they are no longer needed.
• PAM (privileged access management) tools can manage privileged credentials, temporary administrative access, and session recording. CyberArk and Delinea are examples.
• Emergency or break-glass accounts should be protected, monitored, limited in use, and regularly tested.
• Segregation of duties reduces risk by preventing one person from holding conflicting permissions or by requiring additional approval.

Reviews, monitoring, and broader identity needs

Regular access reviews help managers and application owners confirm that permissions remain appropriate. Accounts with no matching current employee record may be orphan accounts.

IGA (identity governance and administration) covers areas such as access requests, approvals, reviews, policies, and evidence for audits. SailPoint and Saviynt are examples.

Logs record sign-ins and important actions. A SIEM collects and correlates security events to support investigation; Microsoft Sentinel and Splunk are examples. A suspicious login location can prompt investigation, but is not by itself proof of an attack.

Risk-based or adaptive authentication can request additional verification or block access when activity appears suspicious. Zero trust means not automatically trusting a request just because a user is on a corporate network or has logged in before. Decisions can consider identity, permissions, device, resource, and policy.

Other identity needs include:

• CIAM, which manages customer identities and emphasizes secure but usable sign-in, account recovery, and scale. Auth0 and Amazon Cognito are examples.
• Partner and contractor access, which may use guest accounts or the partner’s own identity provider. Access should be limited to relevant responsibilities and removed when collaboration ends.
• Non-human identities, such as services, which also need least-privilege access. API keys and secrets should not be embedded in code; Azure Key Vault and AWS Secrets Manager are examples of secure storage options.

Overall architecture

The video presents a typical IAM flow:

1. HR supplies employment data.
2. Identity-management processes determine and review access.
3. An identity provider handles authentication and SSO.
4. Applications enforce permissions.
5. Integrations such as SCIM help provision accounts.
6. Logs feed security monitoring.

These responsibilities may be handled by separate products or combined platforms, but they remain distinct.

Type of content

This is an educational overview and conceptual guide to the IAM ecosystem. It does not provide a product review or a step-by-step configuration tutorial.

Main speaker and examples

The main speaker is a single narrator from Cloud X Berry.

Examples referenced include Microsoft Entra ID, Okta, Active Directory, Microsoft Authenticator, Duo Mobile, YubiKey, CyberArk, Delinea, SailPoint, Saviynt, Microsoft Sentinel, Splunk, Auth0, Amazon Cognito, Azure Key Vault, and AWS Secrets Manager.