Identity and Access Management Concepts
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
A cryptographic boundary is mathematically meaningless if the entity crossing it cannot be definitively identified, authenticated, and constrained. When we build networks, we are essentially constructing digital cities, complete with vaults, file rooms, and public squares. The central problem of cybersecurity is determining who gets to walk into which rooms, and under what conditions. If we fail to engineer a rigorous system for identifying users and verifying their permissions, the most advanced firewalls and encryption protocols simply become steel doors left wide open.
Identity and Access Management (IAM) is not merely an administrative chore; it is the fundamental architectural defense of modern systems. We must track an identity from its inception to its destruction, dynamically bind it to the exact permissions it needs to function, and seamlessly project that trust across entirely different organizations.
Consider what happens when a new systems administrator is hired. They do not merely "appear" in the network. The identity lifecycle consists of creation, provisioning, modification, and deprovisioning phases. If we do not govern these phases methodically, the network devolves into chaos, littered with forgotten accounts and excessive permissions that attackers exploit.
When the administrator begins their job, we execute provisioning, which grants a new user the necessary access rights to perform assigned job functions. This is the translation of an HR event into digital reality. But jobs are not static. As this administrator transitions from managing workstations to managing core routers, their identity enters the modification phase.
This is where a deeply persistent vulnerability is born. Privilege creep occurs when users accumulate unnecessary permissions as they change roles within an organization. It is administratively easy to grant new permissions but takes effort to revoke old ones. Over a five-year tenure, an employee might quietly amass the cumulative rights of three different departments. To combat this, rigorous account maintenance requires periodic reviews of user permissions to prevent privilege creep, ensuring an identity is stripped of historical, unneeded access.
Eventually, the employee will leave the organization. Deprovisioning revokes an employee's system access upon termination or role change. It is critical to understand how we deprovision. System administrators might be tempted to simply delete the user object. This is a severe forensic error. Disabling an inactive account preserves the security audit trail better than immediately deleting the account.
Why disabling matters: Security Information and Event Management (SIEM) systems record activity using unique identifiers (like Security Identifiers, or SIDs, in Windows). If you delete the account, the directory service forgets which human belonged to that SID. If you are investigating a breach six months later, your logs will show malicious activity tied to an unresolvable string of numbers. Disabling the account severs access but preserves the "Rosetta Stone" needed to map logs to human beings.
Once an identity exists, how do we systematically decide what it can touch? We rely on foundational security principles and access control models.
The golden rule of access is the principle of least privilege, which dictates granting users only the bare minimum permissions needed for specific tasks. If a web server only needs to read a database, it should explicitly be denied the ability to write to it.
To prevent catastrophic single points of failure—whether from malice or honest mistakes—we implement separation of duties, which requires dividing critical tasks among multiple users to prevent fraud or error. No single engineer should be able to write, approve, and deploy code to a production environment.
Managing least privilege at an enterprise scale is impossible if we assign permissions user-by-user. Instead, we use Role-Based Access Control (RBAC), which assigns permissions to job functions rather than individual user accounts. You do not give Alice access to the accounting share; you give the Accountant role access, and place Alice in that role.
When systems demand more nuance, we evolve to Attribute-Based Access Control (ABAC), which uses dynamic policies evaluating user, resource, and environmental attributes. ABAC can look at contextual clues. Is the user accessing the file from a known corporate IP? Is the file marked "Top Secret"? What time is it?
Speaking of time, time-of-day restrictions reduce the attack surface by preventing authentication during unmonitored night hours. If an intern in Chicago attempts to log in at 3:00 AM local time, ABAC rules utilizing time-of-day restrictions can outright deny the request, suffocating an attacker who has stolen those credentials and is operating from a different timezone.
To make RBAC or ABAC work, a network needs a central phonebook—a repository of all identities, roles, and attributes.
LDAP organizes identity information in a hierarchical tree structure called a Directory Information Tree. Think of a Directory Information Tree (DIT) like a biological taxonomy or a corporate organizational chart. It categorizes users logically (e.g., Country = US, Organization = Cyber Corp, Common Name = Alice).
However, network administrators must be hyper-vigilant about how LDAP communicates. The Lightweight Directory Access Protocol (LDAP) uses TCP port 389 for unencrypted directory communications. Transmitting authentication queries over TCP 389 allows attackers on the network to easily intercept credentials using packet sniffers. Therefore, modern enterprises exclusively enforce LDAPS (LDAP over SSL/TLS), which uses TCP port 636 to secure directory authentication traffic.
Historically, an employee needed separate passwords for their workstation, their email, the HR portal, and the ticketing system. Single Sign-On reduces password fatigue by minimizing the number of credentials a user must remember. By doing so, it destroys the psychological incentive for users to write passwords on sticky notes or reuse weak passwords.
Single Sign-On (SSO) allows a user to authenticate once and access multiple independent software systems. But SSO traditionally only works within your company's network boundary. What happens when your company uses a third-party cloud service, like Salesforce or an external HR platform? You do not want the external company storing your employees' passwords.
To solve this, identity federation extends Single Sign-On capabilities across different organizations and trust domains.
Federation splits the authentication process into two distinct roles:
- An Identity Provider (IdP) creates, maintains, and manages identity information. This is your organization. You own the truth about whether Alice is an active employee.
- A Service Provider (SP) relies on an Identity Provider to assert the identity of a user. This is the external cloud service. The SP effectively says, "I don't know who you are, but if the IdP vouches for you, I will let you in."
The Languages of Federation: SAML, OAuth, and OIDC
To make the IdP and SP talk, we must rely on standardized federation protocols. They are not interchangeable; they perform fundamentally different jobs.
| Protocol | Primary Purpose | Data Format | Core Function |
|---|---|---|---|
| SAML | Authentication & Authorization | XML | Web-based SSO across enterprise domains |
| OAuth 2.0 | Delegated Authorization | JSON | Granting apps access to resources |
| OIDC | User Authentication | JWT (JSON Web Tokens) | Adds identity context to OAuth |
Security Assertion Markup Language (SAML) is the heavy lifter for enterprise federation. SAML is an XML-based framework for exchanging authentication and authorization data. If your company uses Microsoft Entra ID (the IdP) to log employees into a third-party expense system (the SP), you are likely using SAML. SAML is primarily used for web-based single sign-on across different administrative domains.
How does SAML actually work? SAML delegates the authentication process to an Identity Provider rather than the Service Provider. When Alice navigates to the expense portal, the portal redirects her to the IdP. Alice proves who she is to the IdP. The IdP then generates a cryptographic receipt. A SAML assertion is a digitally signed XML document from an Identity Provider confirming a user's authentication. The IdP hands this signed assertion back to Alice's browser, which forwards it to the Service Provider. The Service Provider verifies the digital signature and lets Alice in.
But what if an application needs to act on a user's behalf, rather than just log them in? Suppose a third-party printing website needs to fetch a document from your Google Drive. You should never give the printing site your Google password.
Instead, we use OAuth. OAuth is an open standard framework specifically designed for delegated authorization. Think of OAuth like a valet key for a car: it lets the valet drive the car, but it won't let them open the glovebox or permanently steal the vehicle. OAuth allows an application to access resources hosted by other web apps on behalf of a user.
It is crucial to understand that the OAuth protocol handles authorization rather than user authentication. OAuth alone does not securely tell the application who the user is; it only provides an access token granting permission to touch specific data.
Because developers kept incorrectly trying to use OAuth for authentication, the industry built a solution on top of it. OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. Where OAuth provides an "access token" to touch data, OpenID Connect provides user authentication capabilities to the OAuth authorization framework by introducing an "ID token."
OpenID Connect issues a JSON Web Token (JWT) to securely transmit information about the authenticated user. This JWT contains "claims"—verified facts about the user, like their email address and when they logged in. By marrying OAuth 2.0 and OIDC, modern web and mobile applications can securely handle both "what the user is allowed to access" and "who the user actually is."
With identities flowing across protocols and federated boundaries, how do we quantify the exact level of trust we place in a digital transaction? We look to the gold standard of identity frameworks.
NIST Special Publication 800-63 defines technical requirements for federal digital identity services. This framework breaks identity trust into three distinct, measurable variables. If you are auditing or engineering a high-security environment, you must evaluate all three:
- Identity Assurance Level (IAL) refers to the robustness of the identity proofing process under NIST 800-63. Before we create an account, how thoroughly did we prove the human is who they claim to be? IAL1 requires no proof (an anonymous email signup). IAL3 requires the user to physically stand in front of an authorized representative with government-issued physical credentials.
- Authenticator Assurance Level (AAL) defines the strength of the authentication process under NIST 800-63. Once the account exists, how hard is it to log in? AAL1 might just be a password. AAL3 requires hardware-based cryptographic authenticators (like a Smart Card or YubiKey) resistant to phishing and man-in-the-middle attacks.
- Federation Assurance Level (FAL) measures the strength of the assertion used in a federated transaction under NIST 800-63. When the IdP sends an assertion (like a SAML assertion or an OIDC JWT) to the SP, how secure is that transmission? FAL measures whether the assertion is cryptographically signed, whether it is encrypted so eavesdroppers cannot read the attributes, and whether it is securely bound to the user's specific session.
When you synthesize these concepts—understanding how to securely provision an identity, constrain it with least privilege, centralize it in a secure directory, extend it across the globe using federated protocols, and measure its reliability using NIST standards—you have mastered the infrastructure of trust. You are no longer just managing accounts; you are architecting the foundational security layer upon which every other system relies.