Identity and Access Management: The Big Picture

Table of Contents

• Module 1: Understanding the Concepts of Identity and Access Management (IAM)
  • Defining Identity and Authentication
  • Defining Access Control
  • Understanding Rights and Privileges
• Module 2: Putting IAM into Practice
  • Understanding Legacy Systems and Single Sign-On
  • Understanding IAM Technologies and Open Standards
  • Demo: Implementing Azure Active Directory IAM
  • Demo: Implementing AWS IAM
  • Demo: Implementing Google Cloud IAM
• Module 3: Implementing IAM Solutions
  • Rolling Out IAM
  • Taking the Next Steps
• Summary

Identity and access management (IAM) is a wide-ranging set of technologies and concepts that has evolved over many years to become a mainstay security aspect of most organizational infrastructure. This course introduces the core concepts of IAM and explains how they can be implemented into existing infrastructure, alongside the main cloud-based IAM providers. By the end, you should have a solid understanding of the main concepts of identity and access management, plus an overview of solutions currently available for on-premise and cloud-based infrastructure.

Basic familiarity with security concepts and cloud technologies is assumed.

Module 1: Understanding the Concepts of Identity and Access Management (IAM)

Before looking at the latest IAM technologies, it is necessary to establish a baseline of foundational knowledge. This module defines identity and authentication, defines access control, and explains what is meant by rights and privileges.

Defining Identity and Authentication

A useful starting point for IAM is the IAAA model of security:

• Identification
• Authentication
• Authorization
• Accounting

When designing IT systems, the general goal is to move away from decentralized authentication toward a centralized system. Centralization brings authentication, authorization, and accounting into a single location, which makes accounts far easier to manage and audit.

flowchart LR
    subgraph Decentralized["Decentralized Model"]
        A1[System A - Local Accounts]
        A2[System B - Local Accounts]
        A3[System C - Local Accounts]
    end
    subgraph Centralized["Centralized Model"]
        C1[Central Directory / IAM Service]
        C1 --> S1[System A]
        C1 --> S2[System B]
        C1 --> S3[System C]
    end

What is an identity?

An identity can be defined as a set of claims about a subject. A subject may be a person, an application, a device, or an organization — in the IAM world, subjects are usually people or user accounts within an organization.

An identity is composed of one or more attributes that describe the subject, such as:

• A name or username
• Date of birth, job title, or organizational role/position
• Geographical location or physical features
• Something the subject possesses

These attributes are used during the process of authentication — when a subject must prove its identity to a system. Each type of attribute used to authenticate represents an authentication factor (sometimes referred to as an authentication protocol). There are five commonly recognized authentication factors:

The first three factors (know / have / are) are the most commonly used in modern authentication systems. “Somewhere you are” and “something you do” are increasingly used as supplementary or risk-based signals.

Multi-Factor Authentication (MFA)

It is now common practice not to rely on a single factor for authentication. Multi-factor authentication (MFA) combines two or more factors in the authentication process. Typical combinations include:

• Smart card (something you have) + PIN (something you know)
• PIN (something you know) + biometric (something you are)
• Username/password (something you know) + an authenticator app pushing a signal to a mobile device (something you have)

flowchart LR
    U[User] -->|Username + Password| Sys[Target System]
    Sys -->|Push Notification| App[Authenticator App on Mobile Device]
    App -->|Approve| Sys
    Sys -->|Access Granted| U

Authorization

Once a subject has been authenticated, it can be authorized. Authorization verifies which objects or resources a subject is permitted to access — this could be a file server or a database, for example — and determines which actions are allowed, typically expressed through file/folder permissions or rights and privileges (covered in more depth later in this module). Authorization relies on different types of access control systems, discussed in the next section.

Accounting

The final “A” in AAA is accounting. Accounting allows administrators and auditors to:

• Ensure availability and confirm that the correct users can access the resources they are entitled to
• Support compliance and governance requirements, including formal audits
• Indicate security violations when unauthorized access has taken place
• Support security logging for investigations

Good accounting practices are essential to the overall security of an organization’s resources.

Defining Access Control

Authorization is a fundamental part of identity and access management, since it governs how a subject gains access to an object (a resource).

A user account’s access is controlled through a series of permissions, typically administered through security groups (for example, within Active Directory or other directory services). Grouping accounts by shared access requirements — such as a Sales group or an HR group — allows an administrator to define once what a group of users can do (read, write, etc.) rather than configuring access per individual user.

Typical resource types governed by access control include files and folders on network shares, database records, and web-based content on internal or external networks.

Access control is governed by three key models:

Discretionary Access Control (DAC): Permissions are granted by the owner/creator of the data, who decides who is on the access list and what permissions they receive. DAC implementations rely on discretionary access control lists (DACLs). Security groups are normally created within DAC systems to simplify administration for multiple users who require the same access.

Mandatory Access Control (MAC): Access is controlled in accordance with the organization’s security policy rather than the data owner’s discretion. MAC is based on high-security classification systems and is generally reserved for highly classified environments.

Role-Based Access Control (RBAC): Users are grouped according to their job or role. RBAC is effectively a simplified version of DAC and has become very popular, especially for cloud-based resources, as well as for assigning administrative rights and privileges.

flowchart TD
    AC["Access Control Models"] --> DAC["Discretionary Access Control (DAC)<br/>Owner-defined ACLs"]
    AC --> MAC["Mandatory Access Control (MAC)<br/>Policy/classification-based"]
    AC --> RBAC["Role-Based Access Control (RBAC)<br/>Grouped by job role"]

Understanding Rights and Privileges

As a user on an internal network, you are granted certain rights and privileges for using systems, once you have authenticated and proven your identity. The type of account you hold determines the rights and privileges you are afforded, and this also depends on the type of network you are logging on to — for example, local rights and privileges versus network/domain-based rights and privileges.

Basic operations that require rights include:

• Logging on to a computer (the most basic right)
• Accessing the network and resources from network servers
• Turning off a computer

A standard user account is generally given only the rights and privileges needed to perform its job or role within the organization.

Privileged/administrative accounts

Administrative accounts — whether local or domain-based — are afforded the rights and privileges required for the specific roles or functions they perform. Not all administrators have all rights and privileges on a network. Within Active Directory, for example, certain groups of administrators are afforded specific privileged access:

• Enterprise Administrators
• Domain Administrators
• More limited administrative roles such as Backup Operators, which can only perform certain functions

Problems with over-privileged accounts

Traditionally, this model has led to several problems:

• Too many administrator accounts existing on the network
• Some administrators (e.g., service desk staff) being given far more rights and privileges than their role actually requires — service desk administrators, for instance, generally do not need domain or enterprise administrator rights
• Increased attack surface: too many administrative accounts increases the chance of compromise, opening multiple opportunities for exploitation by threat actors (malware, unauthorized access, etc.)
• Auditing difficulties caused by too many users holding elevated rights and privileges

Mitigating administrative risk

Several mechanisms exist to mitigate the risk of overprivileged administrative accounts:

• Principle/Policy of Least Privilege — the procedural control underpinning most areas of IAM; users and administrators should be granted only the access necessary to perform their duties.
• Centralizing AAA wherever possible, using systems such as Active Directory or remote access systems like RADIUS.
• Conditional access — access is only granted when certain policies/conditions are met.
• Privileged Identity Management (PIM) — an overarching technology, now widely implemented by cloud providers, that manages and elevates privileged access, including:
  • Just-In-Time (JIT) access — temporary elevation of privileges for a limited time window
  • Just Enough Administration (JEA) — layered in with least privilege to constrain what an elevated account can do, not just for how long
  • Approval workflows — an administrator must approve elevated privilege requests before they are granted
  • Advanced auditing of privileged access assignments and activity

flowchart TD
    Req["User Requests Elevated Access"] --> Approve{"Approval Required?"}
    Approve -->|Yes| Approver["Administrator Approves Request"]
    Approve -->|No / Pre-approved policy| JIT
    Approver --> JIT["Just-In-Time (JIT) Access Granted"]
    JIT --> JEA["Just Enough Administration (JEA)<br/>Scope Limited to Required Tasks"]
    JEA --> Expire["Access Automatically Expires"]
    Expire --> Audit["Audited / Logged for Accounting"]

Module 2: Putting IAM into Practice

This module covers legacy single sign-on systems, the open standard protocols used across modern IAM platforms, and demonstrations of IAM implementations across three major cloud providers: Microsoft Azure, Amazon Web Services, and Google Cloud.

Understanding Legacy Systems and Single Sign-On

Traditionally, accounts are created and administered using centralized directory services such as Active Directory. Administrators create accounts to support users, computers, and administrators themselves. Access is granted either to privileges or to resources, and accounts may also include service accounts. Active Directory also allows administrators to create security groups, which grant users, computers, and administrators access to resources.

This all happens within a trusted environment called a domain — a domain establishes a security boundary for accounts, and access is granted based on the establishment of trust. These trust relationships are central to IAM.

Kerberos

A classic example of single sign-on built on trust and centralized authentication is Kerberos. In this model:

1. A user wishes to log on to the domain and sends their credentials to the central (local) Domain Controller.
2. The Domain Controller runs multiple services, including the Authentication Service, which checks the identity using the credentials/authentication factors supplied.
3. The Domain Controller also runs the Key Distribution Center (KDC), which manages the Ticket-Granting Ticket (TGT) and the Ticket-Granting Service (TGS).
4. Once authenticated, the KDC issues the user a TGT, encrypted using the Ticket-Granting Service’s secret key.
5. When the user/client wants to access a resource (e.g., a shared folder on a file server), the Ticket-Granting Service validates and authorizes the account, then creates a valid session key for that account to access the resource.

sequenceDiagram
    participant U as User/Client
    participant AS as Authentication Service (DC)
    participant KDC as Key Distribution Center
    participant TGS as Ticket-Granting Service
    participant R as Resource / File Server

    U->>AS: Submit credentials
    AS->>KDC: Verify identity
    KDC-->>U: Issue Ticket-Granting Ticket (TGT)
    U->>TGS: Request access to resource + TGT
    TGS->>TGS: Validate & authorize
    TGS-->>U: Issue Session Key / Service Ticket
    U->>R: Present Session Key
    R-->>U: Grant access to resource

Active Directory and Kerberos together are a great example of centralizing AAA — everything is stored within the security logs on the Domain Controller and administered from a central location. (Kerberos takes its name from the three-headed dog of Greek mythology, representing the three parties — client, KDC, and service — that must trust each other for access to be granted.)

Trusts, forests, and federation

Accounts are held within an Active Directory domain, and trusts can be extended between interlinked/connected domains within an Active Directory tree and forest environment. Trusts can also be extended between two separate Active Directory forests — for example, to support organizations going through a merger, or separate arms of an organization with distinct forests. This requires significant administrative skill and can be difficult to manage on-premise, but it works well for supporting IAM within trusted domains and forests.

To extend trust outside the Active Directory realm, organizations can use a federation service. Federation allows internal accounts, already using single sign-on for internal Active Directory resources, to also gain access to external, web-based resources. Federation uses a series of claims presented against web-based resources, potentially spanning many different organizations, and requires a trust relationship with the resource provider governed by user access policies and permissions. Active Directory Federation Services (AD FS) uses the SAML open standard protocol to make this possible.

flowchart LR
    subgraph OrgDomain["Internal Active Directory Domain/Forest"]
        User[Authenticated User] --> ADFS[AD Federation Services]
    end
    ADFS -->|SAML Claims / Trust| SP1[External Web-Based Resource / Service Provider A]
    ADFS -->|SAML Claims / Trust| SP2[External Web-Based Resource / Service Provider B]

Understanding IAM Technologies and Open Standards

Internet-based IAM systems rely on a number of core open standard technologies to support authentication and authorization:

flowchart TD
    Std["Open IAM Standards"] --> SAML["SAML<br/>Federated AuthN/AuthZ assertions"]
    Std --> OpenID["OpenID<br/>Decentralized authentication"]
    Std --> OAuth["OAuth<br/>Delegated authorization for 3rd-party apps"]
    Std --> SCIM["SCIM<br/>Cross-domain identity provisioning"]

With this foundational knowledge in place, the following sections walk through how these concepts appear in practice across three major cloud IAM platforms.

Demo: Implementing Azure Active Directory IAM

This walkthrough provides a high-level overview of key features for controlling accounts and access control using Microsoft’s Azure IAM tooling.

1. Microsoft 365 Admin Center — a central portal providing an overview of users, teams and groups, roles, and resources, and access to other admin centers, without needing to dive into full Azure Active Directory detail.
   • Selecting an individual user (e.g., “Bob”) allows administration of their account, devices, licenses, applications, mailbox, and OneDrive settings.
   • From here, administrators can also manage user roles and configure multifactor authentication types.
2. Azure Active Directory — the main portal for managing IAM in Azure, with feature highlights on the overview page for:
   • Access control
   • Authentication methods
   • Conditional access
   • Direct links to Privileged Identity Management (PIM) and Azure Active Directory Domain Services
3. Active Users — create new users; manage MFA, group membership, and conditional access settings. Groups and devices/computers can also be managed here, potentially synchronized with an on-premise Active Directory.
4. Roles and administration — select a user to control assigned roles, manage group membership, and review assigned authentication methods.
5. Protect & secure section:
   • Conditional Access policies — create policies requiring, for example, that access originate from trusted locations, use MFA, or come from a specific managed device.
   • Identity Protection — review risk policies such as risky sign-ins.
   • Authentication methods — built-in methods can be allocated to specific users who must use them to authenticate.
6. Identity Governance section:
   • Entitlement Management — control access to resources for different groups, particularly useful for external groups/users accessing internal resources, leveraging policies and role assignments.
   • Access Reviews.
   • Privileged Identity Management (PIM) — manage access using Just Enough Administration (JEA) to enforce least privilege, and activate Just-In-Time (JIT) access, assigning roles to users only for a limited period; after that period elapses, further access must be requested or is denied.
   • Discover and monitor — accounting features providing notifications and review of granted assignments.
   • Additional tools: lifecycle workflows, administration of external identities, and configuration of third-party identity providers.

Demo: Implementing AWS IAM

This walkthrough covers implementing IAM solutions in Amazon Web Services, including account controls and access controls.

1. AWS IAM Identity Center — found under Security, Identity, & Compliance in the Services menu. Provides:
   • The IAM portal for managing access to AWS resources.
   • The IAM Identity Center, for managing user access to multiple AWS accounts.
   • Directory Service tools for hosting/managing Active Directory.
   • Resource Access Manager, for sharing AWS resources with other accounts or within AWS Organizations.
2. IAM Identity Center dashboard — recommended setup steps include:
   • Choosing an identity source (defaults to the Identity Center directory, but can be changed under Actions to Active Directory or an external identity provider such as Okta).
   • Configuring authentication methods, including enabling multifactor authentication.
   • Choosing session settings, such as maximum session duration (default 8 hours).
   • Attribute-Based Access Control (ABAC) — allocate attributes for access control, allowing granular permission assignment without relying solely on traditional group membership (comparable to Microsoft’s dynamic access control features).
   • Management settings — delegate administrators, or delete the IAM Identity Center.
3. Creating users — a simple wizard-driven process for adding a user, allocating attributes, and managing group membership (groups are created/managed under the Groups menu).
4. AWS account configuration — select users and assign them to groups; configure permission sets, which can be predefined (e.g., AdministratorAccess) or customized.
   • Permission set wizard also allows configuring Just Enough Administration and Just-In-Time administration, including session duration (default 1 hour for a given permission set).
5. Application assignments — add bespoke or SAML 2.0–based cloud applications from a list of pre-integrated applications, or create a custom application, then allocate to users/groups.
6. Access Management dashboard (separate from Identity Center):
   • Manage/create groups and allocate users.
   • Assign roles (built-in or custom) and the policies that underpin them (built-in or custom).
   • Configure identity providers — SAML (e.g., AD FS) by default, or OpenID Connect, to establish trust between AWS accounts.
   • Account settings — configure and edit password policies and the security token service endpoints.
   • Access reports — accounting features for analyzing access across the portal.

Demo: Implementing Google Cloud IAM

This walkthrough covers Google Cloud IAM, including account controls and access controls.

1. Google Workspace Admin console — dashboard widgets provide an overview of domain and directory configuration.
2. Directory menu:
   • Manage users via a setup wizard; view user status, including last sign-in.
   • Manage groups — built-in Google Cloud groups, or custom groups created via a wizard (name, group email, group owner). Groups can be configured as security groups to control access to data.
   • Access settings — toggle through access type labels to restrict access according to requirements, with further customization available.
3. Organizational units and directory settings:
   • Create organizational units.
   • Synchronize with directories using LDAP (Lightweight Directory Access Protocol), including synchronization with Active Directory.
   • Configure devices, endpoints, and applications.
4. Security features:
   • Authentication — enable MFA via two-step verification, either enforced globally or for specific date ranges; configure verification methods and security codes.
   • Login challenges — additional security measures to verify a user’s identity when required.
   • Single sign-on — configure with SAML applications or third-party identity providers.
   • Password management — configure password length and strength requirements.
5. Google Cloud IAM (built-in):
   • Review identity and organization settings.
   • Analyze policies and organizational policies.
   • Review audit logs for accounting purposes.

flowchart TD
    subgraph Azure["Microsoft Azure AD IAM"]
        AZ1["365 Admin Center"] --> AZ2["Azure Active Directory"]
        AZ2 --> AZ3["Conditional Access / Identity Protection"]
        AZ2 --> AZ4["Identity Governance / PIM (JIT + JEA)"]
    end
    subgraph AWS["AWS IAM"]
        AW1["IAM Identity Center"] --> AW2["Identity Source (AD / External IdP)"]
        AW2 --> AW3["Permission Sets (ABAC, JIT/JEA)"]
        AW1 --> AW4["Access Management (Roles, Policies, IdPs)"]
    end
    subgraph GCP["Google Cloud IAM"]
        GC1["Workspace Admin Console"] --> GC2["Directory / Groups / OUs"]
        GC2 --> GC3["Security (2-Step Verification, SSO, Password Policy)"]
        GC2 --> GC4["Cloud IAM Policies & Audit Logs"]
    end

Comparison of the three cloud IAM platforms:

Module 3: Implementing IAM Solutions

Rolling Out IAM

Most typical environments include a mixture of on-premise resources and authentication systems alongside cloud-based services. Cloud services can take many forms:

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)
• Identity as a Service (IDaaS) — the primary focus of this course

Most organizations also support remote access users — for example, users working from home who require remote access to internal or cloud-based resources. This combination of private on-premise resources and commercially available cloud resources means organizations are typically operating within a hybrid cloud environment.

flowchart LR
    subgraph OnPrem["On-Premise"]
        AD[(Active Directory)]
        ADFS2[AD Federation Services]
    end
    subgraph Cloud["Cloud-Based Services"]
        IDaaS["Identity as a Service (IDaaS)"]
        SaaS["SaaS Applications"]
        PaaS["PaaS Resources"]
        IaaS["IaaS Resources"]
    end
    Remote[Remote Access Users] --> IDaaS
    AD -- AD Connect / Sync --> IDaaS
    ADFS2 -- Federation / Open Standards --> IDaaS
    IDaaS --> SaaS
    IDaaS --> PaaS
    IDaaS --> IaaS

As seen throughout the module demonstrations, IAM solutions generally support:

• Synchronization/connection with on-premise Active Directory (e.g., Active Directory Connect)
• Synchronization with federated services (e.g., Active Directory Federation Services), using open standard authentication protocols
• Flexibility — “as a Service” providers can be scaled up or down to meet business needs, which fits naturally with IAM
• Accountability/accounting, including more complex auditing arrangements depending on the cloud provider
• Availability — all major cloud IAM providers build redundancy into their systems

CISA/NSA threat mitigation best practices

Security underpins IAM, and best practices for administrators (drawn from CISA and NSA identity and access management guidance) fall into the following categories:

mindmap
  root((CISA/NSA IAM Best Practices))
    Identity Governance
      Centralized policy
      Regulatory compliance
    Environmental Hardening
      Reduce attack surface
    Identity Federation & SSO
      Centralized authN/authZ
      Better threat detection
    MFA
      Move beyond password-only
    Monitoring & Auditing
      Detect suspicious activity
      Faster response

Key considerations when implementing IAM

• Fit with existing infrastructure — cloud-based IAM solutions must work alongside or in place of existing IT infrastructure while meeting business needs; solutions should be future-proofed.
• Resource location — whether resources are on-premise or cloud-based may require additional administration to make them available, and this also affects how applications are accessed by users.
• Data protection (CIA) — security must maintain the balance of Confidentiality, Integrity, and Availability, including an understanding of user working environments and expected user experience.
• Cost — moving to the cloud is often cost-effective, but not always; mixing on-premise and cloud-based resources requires justifying cost against business needs.
• Changing and evolving technologies — cloud-based resources and tools change frequently; expect the portals and features described in this course to evolve over time.
• SLAs and regulatory compliance — service-level agreements and other legal/regulatory compliance documents must be accounted for when moving to the cloud or adopting IAM.
• Training and awareness — both for end users and for implementation/support staff, who need to be adequately trained to support new and evolving IAM technologies.

Taking the Next Steps

To recap, this course covered:

1. The concepts of identity and access management — identity, authentication, authorization, and accounting, and how this underpins cloud-based IAM solutions.
2. Legacy authentication processes such as Kerberos, used to establish Active Directory trusts and federated trust environments, plus the open standards used across most IAM platforms (SAML, OpenID, OAuth, SCIM).
3. A high-level overview of three major IAM providers — Microsoft Azure, Amazon Web Services, and Google Cloud — and the key features each provides.
4. Implementation considerations for rolling out IAM solutions, whether moving to cloud-based or hybrid infrastructure.

For further hands-on learning, all three major providers offer trial accounts that allow you to explore the features covered in this course (and typically much more, depending on the vendor and trial type):

• Microsoft Azure
• Amazon Web Services (AWS)
• Google Cloud

Each vendor also publishes extensive online documentation covering these features in far more depth. In addition, the CISA/NSA identity and access management best practices guidance referenced in the previous section is a strong starting point for further reading.

For further certification-oriented study, relevant learning paths include:

• Microsoft Security, Compliance, and Identity Fundamentals (associated with the SC-900 certification)
• AWS Identity and Access Management fundamentals
• Google Cloud security administration courses
• Identity and Access Management for CISSP, for those focused on the security management side of the discipline

Summary

Identity and access management brings together identification, authentication, authorization, and accounting (IAAA) into a coherent, centralized discipline for securing access to resources — whether on-premise, in the cloud, or across a hybrid environment.

Core principles to remember:

• Centralize authentication, authorization, and accounting wherever possible to simplify management and auditing.
• An identity is a set of claims/attributes about a subject; authentication uses one or more factors (know / have / are / somewhere you are / something you do) to verify that identity.
• Use multi-factor authentication rather than relying on a single factor.
• Choose the right access control model for the job: DAC for flexible owner-managed permissions, MAC for highly classified/regulated environments, and RBAC for scalable, role-driven access — especially in the cloud.
• Apply the principle of least privilege at all times, and use Privileged Identity Management, Just-In-Time access, and Just Enough Administration to minimize standing administrative privilege.
• Legacy centralized authentication (Active Directory/Kerberos) still underpins many environments; federation services (using open standards like SAML) extend trust to external, web-based resources.
• Modern IAM is built on open standards: SAML, OpenID, OAuth, and SCIM — each solving a different piece of the authentication/authorization/provisioning puzzle.
• All major cloud providers (Azure, AWS, Google Cloud) implement the same underlying IAM concepts, with similar (if differently named) capabilities for identity sourcing, conditional/attribute-based access, privileged access management, federation, MFA, and auditing.
• Successful IAM rollout requires balancing security (CIA), cost, evolving technology, SLAs/compliance, and user/staff training.

Quick-reference: IAM standards

Implementation checklist:

• Inventory existing on-premise directory services and identify federation/synchronization requirements.
• Define access control model(s) per resource type (DAC/MAC/RBAC) and standardize on RBAC where possible.
• Enforce MFA across all user accounts, prioritizing privileged accounts first.
• Apply least privilege; move standing admin rights to JIT/JEA-based elevation with approval workflows.
• Establish federation with open standards (SAML/OpenID Connect) for external and SaaS resource access.
• Enable comprehensive auditing/accounting and monitor for risky sign-ins and suspicious activity.
• Map cost, SLA, regulatory, and training requirements before migrating to cloud or hybrid IAM.

Search Terms

identity · access · management · cybersecurity · fundamentals · networking · systems · security · iam · defining