Identity and Access Management

Introduction

Identity and Access Management (IAM) is the discipline of determining who or what is requesting access, verifying that identity, deciding what access is permitted, and recording actions for later review. It applies to employees, contractors, customers, service accounts, applications, devices, and automated processes.

IAM is a core security function because most information-security incidents involve misuse of legitimate credentials, excessive privileges, weak authentication, or poorly managed accounts. Firewalls and endpoint controls may reduce exposure, but they cannot compensate for an account that has inappropriate authority.

A useful security sequence is:

1. Identification: a subject claims an identity.
2. Authentication: the system verifies the claim.
3. Authorization: the system determines what the authenticated subject may do.
4. Accountability: actions are recorded and attributable to an individual or controlled process.

These functions are related but not interchangeable. Entering a username is identification; proving control of an authenticator is authentication; receiving permission to read a file is authorization; and creating an audit record is accountability.

Learning Objectives

By the end of this chapter, a learner should be able to:

• distinguish identification, authentication, authorization, and accountability;
• explain authentication factors and the security value of multifactor authentication;
• apply password-security principles;
• compare discretionary, mandatory, role-based, and attribute-based access control;
• explain role-based access control and the principle of least privilege;
• describe privileged access management;
• design a basic joiner–mover–leaver process;
• identify governance, privacy, legal, and operational risks in IAM; and
• recommend practical controls for a small organization.

1. The IAM Security Model

Subjects, objects, and access decisions

A subject is an active entity requesting access, such as a person, process, application, or device. An object is a resource being accessed, such as a database row, document, server, API, or physical room. An access request can be represented conceptually as:

Subject → request → policy decision → object

The request normally contains an identity, requested operation, target resource, device or network context, and time. The decision may be permit, deny, or permit with conditions, such as read-only access or a requirement for step-up authentication.

A modern IAM architecture separates three functions:

• Policy administration: defines or approves access policies.
• Policy decision: evaluates a request against those policies.
• Policy enforcement: applies the decision at the application, operating-system, database, network, or physical-control layer.

This separation improves consistency and makes it possible to apply common policies across multiple systems.

Figure: The IAM decision flow from identity claim to enforced access and accountability.

Identification

Identification assigns a recognizable name or identifier to a subject. Examples include a username, employee number, email address, device certificate identity, or application client identifier. Identifiers should be unique where accountability is required. Shared accounts weaken attribution and should be avoided except where technically necessary and tightly controlled.

Authentication

Authentication establishes confidence that the subject controls one or more authenticators associated with an identity. It is not proof that the subject is trustworthy in every respect; it is evidence supporting an identity claim.

Authorization

Authorization determines permitted actions after authentication. Permissions should be specific to the required resource and operation. “Can access the payroll system” is less precise than “can view assigned payroll records but cannot export or modify them.”

Accountability

Accountability connects actions to identities and organizational responsibility. It depends on unique accounts, reliable logs, synchronized time, protected audit records, monitoring, and appropriate review. Authentication without logging may establish who signed in but not what that person did.

2. Authentication Factors and Multifactor Authentication

Authentication factors are commonly grouped into three categories:

A factor is not merely a different delivery channel. A password sent by email and a password entered on a website are still knowledge-based authentication. Multifactor authentication (MFA) requires two or more factors from different categories. Two passwords are generally not MFA.

MFA reduces the impact of stolen passwords, although it does not eliminate phishing, session theft, malware, social engineering, or account-recovery attacks. Phishing-resistant methods, especially hardware-backed security keys using modern public-key protocols, provide stronger protection than codes entered into a fraudulent website.

Common methods include:

• Password plus one-time code: convenient but vulnerable to phishing and interception.
• Push approval: useful, but repeated unsolicited prompts can cause “push fatigue.”
• Hardware security key: strongly resists phishing when correctly implemented.
• Smart card or certificate: suitable for managed environments, but requires lifecycle management.
• Biometrics: convenient and difficult to change if compromised; therefore normally used with a device or token rather than as the sole recovery mechanism.

MFA should be prioritized for administrators, remote access, email, financial systems, cloud consoles, and other high-value services. Recovery processes must be protected to the same standard as normal authentication; otherwise an attacker can bypass MFA by convincing support staff to reset the account.

3. Password Security

Passwords remain widely used and must be managed as security credentials rather than ordinary text. Organizations should use long passwords or passphrases, prevent reuse, screen new passwords against known-compromised values, and support password managers.

Systems must not store passwords in plaintext. A password verifier should use a slow, memory-hard password-hashing function with a unique salt for each password. A salt is non-secret random data stored with the verifier. It prevents identical passwords from producing identical stored values and makes precomputed lookup attacks less effective. Encryption alone is not a substitute for password hashing because encrypted passwords can be decrypted if the key is obtained.

Reasonable operational controls include:

• rate limiting and temporary defenses against repeated guesses;
• secure password-reset tokens that expire and are single-use;
• notification of password changes and recovery events;
• no routine forced password changes without evidence of compromise, unless policy or regulation requires otherwise;
• protection against password hints that reveal secrets; and
• secure handling of service-account credentials.

Password complexity rules can produce predictable patterns such as “Spring2025!” and may encourage unsafe reuse. Length, screening against breached-password lists, MFA, and secure recovery are usually more valuable than arbitrary composition rules.

4. Authorization Models

Discretionary Access Control

In Discretionary Access Control (DAC), the owner of a resource can often grant access to other users. DAC is flexible and common in file systems, but users may unintentionally share sensitive information. Ownership and permission inheritance must therefore be governed carefully.

Mandatory Access Control

In Mandatory Access Control (MAC), access is determined by centrally managed security labels and rules. Users cannot override the policy merely because they own a file. MAC is useful where confidentiality classifications or highly controlled environments are important.

Role-Based Access Control

In Role-Based Access Control (RBAC), permissions are assigned to roles, and users receive roles according to job responsibilities. A simplified relationship is:

This expression assumes that permissions are not denied by a higher-priority rule and that contextual conditions do not remove access. In practice, organizations also need separation-of-duty constraints, time limits, resource scopes, and exception handling.

Typical roles include accounts-payable clerk, help-desk analyst, nurse, database administrator, and security auditor. RBAC reduces administration compared with assigning permissions individually, but poorly designed roles can become excessive “super roles.” Roles should be based on actual tasks, reviewed regularly, and tested for conflicts.

Attribute-Based Access Control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, resource, action, and environment. An example policy might permit a clinician to view a patient record only when the clinician is assigned to that patient, the purpose is treatment, and the session uses an approved device. ABAC supports fine-grained decisions but requires reliable attribute sources and more complex policy management.

Least privilege and separation of duties

The principle of least privilege grants only the access necessary for an authorized task, for the minimum practical duration. It limits both accidental damage and the consequences of a compromised account.

Separation of duties prevents one person from completing an entire sensitive process alone. For example, one employee may create a supplier and another may approve payment. This control reduces fraud and errors but must be designed so that small teams can still operate effectively. Compensating controls, such as independent review, may be required where staffing makes strict separation impractical.

5. Privileged Access Management

Privileged accounts can alter configurations, create accounts, disable controls, access sensitive data, or affect many systems at once. Examples include domain administrators, cloud-root users, database administrators, hypervisor administrators, and emergency “break-glass” accounts.

Privileged Access Management (PAM) is a set of processes and technologies for controlling, monitoring, and reviewing elevated access. Core practices include:

• separate administrative and ordinary user accounts;
• eliminate unnecessary standing privilege;
• grant just-in-time or time-limited elevation where feasible;
• require MFA for privileged access;
• store credentials in a protected vault and rotate them;
• record administrator sessions where lawful and proportionate;
• restrict administrative paths and approved devices;
• alert on unusual privilege use; and
• test emergency accounts without leaving them permanently active.

PAM is not simply a password vault. It includes approval workflows, technical enforcement, session accountability, credential lifecycle management, and periodic review. Automation can reduce manual errors, but automated elevation policies must be carefully tested because a faulty rule may grant broad authority at machine speed.

6. Joiner–Mover–Leaver Lifecycle Management

Identity risk changes when a person joins, changes duties, or leaves. The joiner–mover–leaver (JML) process integrates human-resources records, management approval, IAM systems, application owners, and security operations.

Joiners

Before access is granted, the organization should verify the person’s identity, employment status, manager, location, job function, and required systems. A standard role can provide a baseline, while exceptional access requires documented justification and approval. The account should be created only after the authoritative HR record exists, and initial credentials should be delivered securely.

Movers

When a person changes department, project, location, or responsibility, old access must be reviewed rather than simply adding new permissions. A mover process should compare previous and new roles, remove incompatible access, preserve only justified continuing access, and consider separation-of-duty conflicts.

Leavers

Termination or contract expiry should trigger prompt disabling of accounts, revocation of sessions and tokens, return of devices and badges, transfer or preservation of business records, removal from groups and mailing lists, and review of delegated access. The timing should reflect the risk: involuntary termination may require coordinated immediate action, while a planned departure may use a scheduled process.

A sound JML process has an owner, defined service levels, evidence of approvals, exception handling, reconciliation with target systems, and periodic audits. Orphaned accounts, dormant accounts, and accounts belonging to departed workers are important indicators of process failure.

7. IAM Governance and Accountability

IAM requires governance as well as technology. Important responsibilities include:

• Identity owner: maintains the authoritative identity record.
• Manager: confirms business need for access.
• Resource owner: determines who may use a system or data set.
• IAM administrator: implements approved changes.
• Security team: monitors, investigates, and advises.
• Auditor or compliance function: evaluates control effectiveness.

Access reviews should ask meaningful questions: Does the user still need this access? Is the role appropriate? Is the access being used? Does it conflict with another responsibility? Merely clicking “approve all” is not an effective review.

Logs should record successful and failed authentication, privilege changes, account creation and deletion, access-policy changes, sensitive-data access, and administrative actions. Logs should be protected from unauthorized alteration and retained according to risk, legal requirements, and organizational policy. Monitoring must respect privacy and should collect proportionate information.

8. Legal, Ethical, and Privacy Considerations

IAM supports compliance with privacy, records-management, financial, health, and cybersecurity obligations, but compliance is context-dependent. Organizations must identify applicable laws and contractual requirements rather than assuming that one framework applies everywhere.

Common governance principles include data minimization, purpose limitation, confidentiality, accuracy of identity records, controlled disclosure, and retention limits. Biometric information deserves particular care because it is sensitive and generally cannot be replaced like a password. Organizations should assess necessity, provide suitable alternatives where appropriate, protect templates, and establish deletion and access procedures.

Monitoring privileged users can be justified by security needs, but it should be transparent, proportionate, access-controlled, and consistent with employment and privacy law. Excessive surveillance can undermine trust and create a second security risk if monitoring data is poorly protected.

Identity proofing must also be fair and accessible. Processes that require a particular device, biometric capability, physical location, or government document may disadvantage some legitimate users. Secure alternatives and an accountable exception process are important.

9. Practical Implementation Approach

A small organization can improve IAM through a staged program:

1. Inventory users, applications, service accounts, devices, and privileged identities.
2. Identify authoritative sources, usually HR for workforce identities and a customer system for external users.
3. Enforce unique accounts and MFA for high-risk services.
4. Remove dormant, shared, and unnecessary accounts.
5. Define a small set of job-based roles and document exceptions.
6. Establish JML workflows with managers and system owners.
7. Separate ordinary and administrative accounts.
8. Centralize logs and review high-risk events.
9. Introduce privileged-access controls and periodic access certification.
10. Test recovery, emergency access, and termination procedures.

Useful indicators include the percentage of privileged accounts using MFA, time to disable leaver accounts, number of orphaned accounts, percentage of applications integrated with centralized identity services, completion quality of access reviews, and frequency of excessive-privilege findings. Metrics should measure control effectiveness, not merely activity. For example, “number of access reviews completed” is weaker than “percentage of inappropriate permissions removed through access reviews.”

Applied Case: Northbridge Training Services

Background

Northbridge Training Services is a fictional organization with 120 employees. It uses cloud email, a learning-management system, a finance application, and a shared file platform. Employees often change between teaching, administration, and project work.

Problem

The organization discovered that former contractors still had active accounts, several staff members shared a finance login, and managers approved access reviews without examining permissions. A compromised employee password was used to access confidential learner records.

Analysis

The incident involved multiple failures rather than one bad password. Shared accounts weakened accountability, leaver processing was incomplete, access reviews were superficial, and sensitive applications lacked MFA. Some users retained permissions from previous jobs, violating least privilege.

Approach and solution

Northbridge established HR as the authoritative source for workforce status and connected it to a central identity provider. Every worker received a unique account. MFA was required for email, finance, remote access, and administration. The finance shared account was replaced with named accounts and a controlled service identity where necessary.

The organization created baseline roles for teaching, finance, learner support, and management. Exceptions required resource-owner approval and an expiry date. A mover workflow removed old role access before adding incompatible new access. A leaver workflow disabled accounts and revoked active sessions at the termination time. Administrators received separate privileged accounts, and emergency access was stored in a monitored vault.

Outcome

A later access review found and removed dormant accounts and several unnecessary permissions. Investigators could attribute finance changes to named users. The organization also improved its privacy notice and introduced a secure recovery process that did not allow help-desk staff to bypass MFA without independent verification.

Learning points

The case demonstrates that IAM is a lifecycle and governance capability, not merely a login screen. Strong authentication is valuable, but it must be combined with unique identities, least privilege, timely deprovisioning, meaningful reviews, and reliable accountability.

Challenges and Contemporary Developments

Cloud services and software-as-a-service platforms multiply identities and permissions. Organizations increasingly use centralized identity providers, single sign-on, federation, and automated provisioning. These reduce password reuse and administrative effort, but a compromised central identity provider can affect many systems; therefore its administration and recovery require exceptional protection.

Machine identities are also growing rapidly. APIs, containers, workloads, and automated agents need credentials, certificates, or tokens. These identities should have owners, limited permissions, rotation or expiration, secure storage, and monitoring. A service account with permanent administrator access is a significant risk.

Zero Trust architectures treat access as an ongoing decision rather than a one-time grant at network entry. Decisions may consider identity, device health, application, resource sensitivity, session risk, and behavioral signals. Zero Trust does not mean trusting nobody; it means avoiding implicit trust and continuously applying explicit policy.

Artificial intelligence can assist with anomaly detection, identity correlation, entitlement analysis, and access-review prioritization. It should not be treated as an unquestionable authority. False positives can disrupt legitimate work, while false negatives can hide compromise. Human oversight, explainable decisions, protected training data, and documented appeal processes remain necessary.

Chapter Summary

IAM controls the relationship between identities and resources. Identification states an identity claim, authentication verifies that claim, authorization determines permitted actions, and accountability records activity in a traceable manner. Authentication factors are based on knowledge, possession, and inherence; MFA uses different factor categories and is particularly important for privileged and high-value access.

Secure password handling requires strong password hashing, unique salts, protection against guessing, secure recovery, and support for long passphrases and password managers. Authorization models include DAC, MAC, RBAC, and ABAC. Least privilege and separation of duties limit the consequences of error or compromise. PAM applies these principles to elevated accounts through controls such as just-in-time access, vaulting, session monitoring, and approval.

The JML lifecycle ensures that access is created, changed, and removed as employment status changes. Effective IAM also requires governance, meaningful access reviews, protected logs, privacy safeguards, fair identity proofing, and attention to machine identities and cloud services. Technology is important, but reliable ownership, policy, process, and accountability are equally essential.

Key Terms

Accountability: The ability to attribute actions to a responsible identity or process.

Authentication: Verification of a claimed identity.

Authorization: Determination of what an authenticated subject may do.

Attribute-Based Access Control (ABAC): Access control based on subject, resource, action, and environmental attributes.

Identity: A representation of a person, device, application, or other entity in a system.

Identity provider: A service that authenticates identities and supplies assertions or tokens to relying applications.

Joiner–mover–leaver: Lifecycle processes for creating, changing, and removing access.

Least privilege: Granting only the access necessary for an authorized task.

Mandatory Access Control (MAC): Centrally enforced access based on security labels and policy.

Multifactor authentication (MFA): Authentication using two or more different factor categories.

Password hashing: One-way processing of a password for secure verification.

Privileged account: An account with elevated authority over systems, configurations, or data.

Privileged Access Management (PAM): Controls for governing, monitoring, and securing elevated access.

Role-Based Access Control (RBAC): Access control in which permissions are assigned to roles and users receive approved roles.

Salt: Unique non-secret random data combined with a password before hashing.

Separation of duties: Dividing sensitive responsibilities among multiple people or roles.

Service account: A non-human identity used by an application, service, or automated process.

Subject: An active entity requesting access.

Zero Trust: A security approach that avoids implicit trust and evaluates access explicitly and continuously.

Review Questions

Short Answer Questions

1. Distinguish identification from authentication.
2. What are the three major authentication-factor categories?
3. Why should passwords not be stored in plaintext?
4. State the principle of least privilege.
5. What is the purpose of the leaver process?

Long Answer Questions

1. Explain how identification, authentication, authorization, and accountability work together in an access request.
2. Compare RBAC and ABAC, including one advantage and one limitation of each.
3. Describe the main controls expected in a privileged access management program.
4. Explain how separation of duties reduces security and fraud risk.
5. Discuss the privacy and ethical issues associated with biometric authentication and user monitoring.

Analytical / Application Questions

1. A contractor moves from learner support to finance but retains all previous permissions. Analyze the risks and design an appropriate mover process.
2. An organization has MFA for email but allows administrators to use shared passwords for server access. Evaluate the weaknesses and recommend controls.
3. Design a basic IAM improvement plan for a 50-person organization using cloud email, accounting software, and shared storage. Identify priorities, owners, and measures of success.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a claimed identity is genuine?

A. Identification

B. Authentication

C. Authorization

D. Accountability

Correct Answer: B. Authentication

Question 2

Which option represents multifactor authentication?

A. Password and PIN

B. Two passwords

C. Password and security key

D. Username and password hint

Correct Answer: C. Password and security key

Question 3

What is the main purpose of a unique password salt?

A. To make passwords visible to administrators

B. To ensure identical passwords produce identical hashes

C. To reduce the usefulness of precomputed password attacks

D. To replace multifactor authentication

Correct Answer: C. To reduce the usefulness of precomputed password attacks

Question 4

In RBAC, permissions are primarily assigned to what?

A. Roles

B. Network cables

C. Password histories

D. Audit logs

Correct Answer: A. Roles

Question 5

Which principle grants only the access necessary for an authorized task?

A. Open access

B. Least privilege

C. Implicit trust

D. Credential sharing

Correct Answer: B. Least privilege

Question 6

Which is an appropriate privileged-access control?

A. Permanent administrator rights for all staff

B. Shared administrator passwords

C. Time-limited elevation with monitoring

D. Disabling audit logs

Correct Answer: C. Time-limited elevation with monitoring

Question 7

What should normally happen when an employee changes departments?

A. Add new access without reviewing old access

B. Remove all identity records permanently

C. Review and adjust access for the new duties

D. Give the employee administrator access

Correct Answer: C. Review and adjust access for the new duties

Question 8

Which statement best describes accountability?

A. It determines whether a password is long enough

B. It connects actions to a responsible identity or process

C. It grants every user the same permissions

D. It replaces authorization decisions

Correct Answer: B. It connects actions to a responsible identity or process

Question 9

Which control is most directly intended to prevent one person from completing an entire sensitive transaction alone?

A. Separation of duties

B. Password reuse

C. Shared accounts

D. Unrestricted delegation

Correct Answer: A. Separation of duties

Question 10

Why are shared accounts generally discouraged?

A. They always require biometric devices

B. They weaken individual attribution and accountability

C. They cannot be used on cloud systems

D. They prevent all forms of authorization

Correct Answer: B. They weaken individual attribution and accountability