Identity and Access Management

Introduction

Identity and Access Management (IAM) is the discipline of ensuring that the right person, device, application, or service receives the right access to the right resource at the right time—and that the access can be explained afterwards. IAM is therefore both a security function and an operational governance function. It protects confidentiality, integrity, and availability while supporting efficient business activity.

A modern organisation may have employees, contractors, customers, suppliers, cloud services, application programming interfaces (APIs), and automated workloads. Each may require a digital identity. Poorly managed identities create serious risks: stolen credentials, excessive privileges, orphaned accounts, unauthorised access, data leakage, and inability to investigate incidents.

IAM is commonly described through four related activities:

1. Identification: claiming or presenting an identity.
2. Authentication: proving that the claimant controls that identity.
3. Authorization: determining what the authenticated entity may do.
4. Accountability: recording and reviewing actions so that responsibility can be established.

These activities should not be treated as interchangeable. A username identifies a claimed account, but does not prove ownership. A successful login authenticates an entity, but does not automatically grant permission to every system. An access decision without reliable logging weakens accountability.

Learning Objectives

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

• distinguish identification, authentication, authorization, and accountability;
• explain passwords, password storage, multifactor authentication, and biometrics;
• compare discretionary, mandatory, role-based, and attribute-based access control;
• apply least privilege, separation of duties, and zero-trust principles;
• describe privileged access management and the identity lifecycle;
• design practical access-review and deprovisioning procedures;
• evaluate IAM risks, ethical issues, and contemporary developments.

The IAM Security Model

Identification and authentication

Identification begins when an entity presents an identifier such as a username, employee number, email address, certificate subject, or device identity. The identifier is a claim. Authentication tests the claim using one or more credentials.

Authentication factors are usually grouped as follows:

Multifactor authentication (MFA) requires factors from at least two different categories. Entering a password and answering a security question is generally not strong MFA because both are knowledge factors. A password plus a phishing-resistant hardware security key uses different factors and provides stronger protection.

Authentication strength depends on the protocol, not only on the number of factors. A one-time code sent by text message can reduce the impact of password reuse, but it is vulnerable to number-porting fraud and some forms of interception. A cryptographic security key can resist many phishing attacks because it verifies the legitimate website origin before releasing proof.

Authorization

Authorization is the decision to permit or deny an action on a resource. A useful access-control statement contains at least:

• Subject: the user, service, process, or device requesting access;
• Object: the file, database, system, record, or service being accessed;
• Action: read, create, modify, delete, execute, approve, or administer;
• Context: time, location, device health, business purpose, and risk.

For example, a payroll officer may read and update payroll records during working hours from a managed device, but may not approve their own salary change. Authorization should be evaluated for each sensitive action rather than inferred from successful login alone.

Accountability

Accountability links an action to an identity and provides evidence for investigation, compliance, and improvement. Effective accountability requires reliable timestamps, authenticated identities, meaningful event descriptions, protected logs, and procedures for review. Shared accounts weaken accountability because it becomes difficult to determine which individual performed an action.

A log entry should normally capture the subject, action, object, result, time, source device or network, and relevant transaction identifier. Logs should be protected against unauthorised alteration, retained according to legal and operational requirements, and monitored for suspicious patterns. Logging excessive personal information can itself create privacy risks, so collection should be proportionate.

Passwords and Credential Protection

Passwords remain common because they are inexpensive and easy to deploy, but they are vulnerable to guessing, phishing, credential stuffing, keylogging, malware, and reuse across services. A strong password policy should encourage long, unique passwords or passphrases and should avoid rules that cause predictable substitutions such as replacing “o” with “0”. Password managers can generate and store unique credentials, reducing reuse.

Systems must not store passwords in plaintext. Instead, a password is processed by a password-hashing function with a unique salt. A salt is a random value stored with the password hash; it prevents identical passwords from producing identical stored values and makes precomputed rainbow-table attacks less effective. Password-hashing functions should be deliberately expensive and memory-hard where appropriate, such as Argon2id, rather than using a fast general-purpose hash alone.

Conceptually, a stored password verifier can be represented as:

Here, v is the stored verifier, p is the password, s is the unique salt, c represents cost parameters, and H is an approved password-hashing function. The system recomputes the verifier when the user logs in and compares the result. The formula describes a conceptual process; the exact encoding and parameters depend on the selected algorithm.

Passwords should be transmitted only through protected channels such as properly configured TLS. Failed attempts may be rate-limited, but simplistic lockout policies can enable denial-of-service attacks against legitimate users. Detection should consider password spraying, credential stuffing, unusual locations, impossible travel, and abnormal device behaviour.

Multifactor Authentication and Biometrics

MFA substantially reduces the risk associated with stolen passwords, especially for remote access, administrator accounts, cloud consoles, and sensitive applications. However, MFA is not automatically phishing-proof. Attackers may proxy a victim’s login to a genuine service or socially engineer a user into approving a fraudulent push notification. Number matching, transaction details, rate limits, and phishing-resistant authentication improve resilience.

Biometrics use physical or behavioural characteristics. They are convenient, but they present special concerns. A password can be changed after compromise; a fingerprint or facial pattern cannot easily be replaced. Biometric systems therefore commonly store a protected template rather than a recoverable image, and they should provide an alternative method for users who cannot or do not wish to use a biometric.

Important biometric concepts include:

• False acceptance rate (FAR): the probability that an unauthorised person is accepted.
• False rejection rate (FRR): the probability that an authorised person is rejected.
• Liveness detection: testing whether the presented characteristic comes from a live person rather than a photograph, recording, or artificial replica.

Reducing the decision threshold may improve convenience but can increase false acceptance. Biometric deployment must consider demographic performance differences, accessibility, informed consent, retention, purpose limitation, and legal requirements.

Access-Control Models

Discretionary Access Control

In Discretionary Access Control (DAC), resource owners decide who may access an object. File permissions and access-control lists are familiar examples. DAC is flexible and practical, but users may accidentally grant access or copy information to less-protected locations.

Mandatory Access Control

Mandatory Access Control (MAC) applies centrally defined classifications and clearances. A subject’s clearance and an object’s classification determine access. Users cannot normally override policy. MAC is useful where information classification and strong central control are essential, such as defence or highly regulated environments.

Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to job roles, and users receive roles according to their responsibilities. A nurse, lecturer, database administrator, and help-desk analyst may each receive different role sets. RBAC improves manageability, but poorly designed roles can become excessive or difficult to maintain. Role engineering should begin with business duties and separate incompatible responsibilities.

Attribute-Based Access Control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, object, action, and environment. A policy might allow a case worker to read a client record only when the worker is assigned to that case, uses a managed device, and operates during an approved period. ABAC supports fine-grained and contextual decisions but requires reliable attributes, policy governance, and careful testing.

Least privilege and separation of duties

Least privilege gives an entity only the access necessary for its current task and for no longer than necessary. It limits damage when an account or device is compromised. Separation of duties ensures that a sensitive process is divided among people or systems. For example, one employee may prepare a payment while another approves it. These controls reduce fraud and error, but they must be designed so that staff can still perform their work during emergencies.

Zero trust

Zero trust is an architectural approach rather than a single product. It assumes that network location alone does not establish trust. Access decisions should use continuously evaluated identity, device, application, and context signals; grant least privilege; and limit the scope and duration of sessions. Zero trust does not mean that every request is rejected. It means that access is explicitly verified and continually controlled.

Privileged Access Management

Privileged accounts can change security settings, create users, alter systems, access sensitive data, or disable controls. Examples include domain administrators, cloud-root accounts, database administrators, and service accounts with broad permissions. Their compromise can affect an entire organisation.

Privileged Access Management (PAM) should include:

• separate administrative accounts rather than using administrator rights for routine work;
• strong MFA and phishing-resistant methods where possible;
• approval or justification for high-risk actions;
• just-in-time, time-limited privilege;
• password vaulting and automated rotation for managed secrets;
• session recording or detailed command logging where lawful and proportionate;
• emergency “break-glass” accounts protected by strict monitoring and post-use review;
• regular review of human and non-human privileged accounts.

Service accounts deserve special attention. They should have an identified owner, a documented purpose, minimal permissions, managed credentials, and a replacement or disablement plan. Hard-coded secrets in source code and configuration files should be replaced with a secrets-management mechanism.

The Identity Lifecycle

IAM is a lifecycle, not merely a login screen. A typical lifecycle includes:

1. Joiner: identity creation, proofing, employment or contract verification, role assignment, and secure credential delivery.
2. Mover: modification of access after transfer, promotion, leave, or change of duties. Old access must be removed rather than simply adding new access.
3. Leaver: prompt disabling of accounts, revocation of sessions and tokens, recovery of devices, transfer of records, and review of owned resources.
4. Periodic review: managers and resource owners confirm that access remains necessary and appropriate.

Identity proofing should be proportional to risk. A user requesting access to a public newsletter needs less verification than a person receiving access to financial records. Organisations should define authoritative sources for employment status and role information, automate routine provisioning where safe, and maintain evidence of approvals.

Federated identity allows one identity provider to authenticate users for multiple relying services. Standards such as SAML and OpenID Connect support federation, while OAuth 2.0 is primarily an authorization framework for delegated access. These technologies reduce password proliferation but create concentration risk: compromise of a central identity provider may affect many services. Federation therefore requires strong provider protection, careful token validation, appropriate audience and scope restrictions, and reliable offboarding.

Applied Case: Northbridge College Identity Renewal

The following is an illustrative case.

Background

Northbridge College used separate accounts for its learning platform, finance system, laboratory computers, and remote-access gateway. Several lecturers shared laboratory administrator passwords, and student assistants retained access after their contracts ended. The security team also found that managers approved access by email without a consistent review schedule.

Problem

The college faced credential reuse, excessive privileges, weak accountability, and delayed deprovisioning. A compromise of a shared administrator password could have affected research data and student records.

Analysis

The college mapped identities, systems, data classifications, and business owners. It identified privileged accounts, service accounts, orphaned accounts, and incompatible duties. It rated systems according to the harm that could result from unauthorised access. The analysis showed that the most urgent controls were MFA for remote and privileged access, removal of shared accounts, automated joiner–mover–leaver processes, and formal access reviews.

Approach and solution

The college introduced a central identity provider with federation to major applications. Students and staff received unique accounts, while laboratory administration used separate named privileged accounts. Phishing-resistant security keys were issued to administrators; other high-risk users received MFA based on approved methods. RBAC was used for standard academic and administrative duties, with contextual checks for sensitive systems.

A human-resources feed triggered joiner and leaver workflows. Role changes created review tasks and removed incompatible permissions. Service accounts were assigned owners and moved into a secrets vault. A quarterly review required managers to confirm access, while system owners reviewed privileged permissions monthly. Security logs were centralised, protected, and monitored for unusual administrative behaviour.

Outcome

Shared administrator credentials were eliminated, inactive accounts were disabled promptly, and access reviews produced evidence suitable for audit. Staff initially reported inconvenience, so the college provided password-manager training, clear recovery procedures, and a staged rollout. The result was stronger security without requiring every user to become an IAM specialist.

Learning points

The case demonstrates that IAM is primarily a governance and process challenge supported by technology. MFA alone would not have solved stale accounts, excessive privileges, or poor accountability. Effective IAM combines identity data, policy, authentication, authorization, logging, user support, and continuous review.

Governance, Ethics, and Limitations

IAM decisions affect employment, privacy, accessibility, and personal autonomy. Organisations should collect only identity information needed for a defined purpose, protect it throughout its lifecycle, and explain important decisions. Biometric and behavioural data require especially careful handling because misuse or compromise may cause lasting harm.

Access systems can reproduce organisational bias. For example, a role model based on outdated job categories may deny legitimate work or grant inappropriate access. Automated risk scoring may also produce false positives for travelling staff, people with disabilities, or users sharing constrained network infrastructure. Human review, appeal channels, testing, and documented accountability are necessary.

Legal and regulatory obligations vary by jurisdiction and sector, but commonly include privacy, records protection, breach reporting, employment, accessibility, and industry-specific security requirements. Compliance does not replace security judgment: a technically compliant design may still be unsafe if its permissions are excessive or its logs are not reviewed.

Common implementation failures include treating RBAC as a one-time project, granting permanent administrator rights for convenience, ignoring non-human identities, relying on SMS as the only high-risk MFA method, and failing to test recovery procedures. IAM controls should be measured by meaningful outcomes such as reduction in dormant accounts, completion of access reviews, time to revoke access, privileged-session coverage, and confirmed policy exceptions—not merely by the number of controls deployed.

Contemporary Developments and Best Practices

Contemporary IAM increasingly includes cloud identities, workload identities, passwordless authentication, adaptive access, decentralized identity experiments, and machine-learning-assisted anomaly detection. AI can help identify unusual login patterns or recommend removal of unused permissions, but its recommendations require human oversight, quality data, explainability, and protection against manipulation. AI should not be treated as an authority that automatically grants or revokes access in high-impact contexts without safeguards.

A practical IAM programme should:

• maintain an authoritative inventory of identities, accounts, owners, and privileges;
• use unique identities and prohibit routine shared accounts;
• apply least privilege, separation of duties, and risk-based MFA;
• use secure password hashing and protected credential storage;
• prefer phishing-resistant authentication for administrators and sensitive systems;
• automate provisioning and deprovisioning from trusted personnel data;
• review privileged and high-risk access more frequently than ordinary access;
• protect logs and monitor authentication and authorization events;
• test emergency access, recovery, and offboarding procedures;
• document exceptions with an owner, expiry date, and compensating controls;
• train users without blaming them for sophisticated social engineering;
• assess privacy, accessibility, fairness, and legal requirements throughout design.

Chapter Summary

Identity and Access Management establishes who or what is requesting access, verifies the claim, decides what actions are permitted, and preserves evidence of those actions. Authentication may use knowledge, possession, inherence, or contextual factors; MFA is strongest when it combines independent factors and resists phishing. Passwords should be long, unique, transmitted through protected channels, and stored using salted, deliberately expensive password-hashing functions.

DAC, MAC, RBAC, and ABAC provide different ways to structure authorization. Least privilege, separation of duties, zero-trust principles, and privileged access management reduce the impact of compromise. IAM must cover joiners, movers, leavers, service accounts, federated identities, periodic reviews, and emergency access. Effective programmes combine technology with governance, privacy, accessibility, user support, logging, and continuous improvement.

Key Terms

Identification: Presentation or claiming of an identity.

Authentication: Verification that a claimant controls an identity.

Authorization: Decision about permitted actions on a resource.

Accountability: Ability to attribute and review actions.

Credential: Evidence used to authenticate an identity.

Multifactor authentication: Authentication using at least two different factor categories.

Password hash: One-way computational representation used for password verification.

Salt: Unique random value added to a password before hashing.

Biometrics: Authentication based on physical or behavioural characteristics.

False acceptance rate: Probability that an unauthorised claimant is accepted.

Discretionary Access Control: Access controlled by the resource owner.

Mandatory Access Control: Access controlled by central classifications and clearances.

Role-Based Access Control: Access assigned through organisational roles.

Attribute-Based Access Control: Access determined by subject, object, action, and environmental attributes.

Least privilege: Granting only the access necessary for a task.

Separation of duties: Dividing sensitive responsibilities among people or systems.

Privileged account: Account with powerful administrative or security permissions.

Identity lifecycle: The processes managing identities from creation through removal.

Federated identity: Use of one identity provider across multiple relying services.

Zero trust: Security approach that explicitly verifies requests and limits implicit trust.

Review Questions

Short Answer Questions

1. Distinguish identification from authentication.
2. What makes authentication multifactor rather than merely multi-step?
3. Why should passwords be salted before being processed by a password-hashing function?
4. State two risks associated with shared administrator accounts.
5. What is the purpose of a periodic access review?

Long Answer Questions

1. Compare DAC, MAC, RBAC, and ABAC, including an appropriate use case and limitation for each.
2. Explain how least privilege, separation of duties, and zero trust complement one another.
3. Describe a secure joiner–mover–leaver process for a medium-sized organisation.
4. Discuss the security and privacy advantages and limitations of biometric authentication.
5. Explain the main components of a Privileged Access Management programme.

Analytical / Application Questions

1. A contractor changes from software testing to finance administration but retains all previous permissions. Analyse the risks and design a mover process to correct them.
2. An organisation has MFA based only on passwords and SMS codes for cloud administrators. Evaluate the design and recommend improvements.
3. Design an IAM control plan for a college with students, staff, visiting researchers, cloud applications, laboratory devices, and emergency administrator accounts.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a claimant controls a presented identity?

A. Identification

B. Authentication

C. Authorization

D. Accountability

Correct Answer: B. Authentication

Question 2

Which combination is an example of multifactor authentication?

A. Password and PIN

B. Fingerprint and facial recognition

C. Password and hardware security key

D. Username and password

Correct Answer: C. Password and hardware security key

Question 3

What is the primary purpose of a unique password salt?

A. To make a password shorter

B. To prevent identical passwords from producing identical stored values

C. To allow passwords to be recovered in plaintext

D. To replace multifactor authentication

Correct Answer: B. To prevent identical passwords from producing identical stored values

Question 4

Which access-control model assigns permissions through organisational job roles?

A. DAC

B. MAC

C. RBAC

D. ABAC

Correct Answer: C. RBAC

Question 5

Which principle gives an account only the permissions required for its current task?

A. Least privilege

B. Open trust

C. Credential sharing

D. Maximum availability

Correct Answer: A. Least privilege

Question 6

Which is a recommended control for privileged accounts?

A. Using one shared administrator password

B. Permanent administrator rights for all staff

C. Just-in-time, time-limited privilege

D. Disabling administrative logging

Correct Answer: C. Just-in-time, time-limited privilege

Question 7

What should normally happen when an employee changes job roles?

A. Only new permissions should be added

B. All permissions should remain unchanged

C. Old access should be reviewed and unnecessary access removed

D. The employee should receive a shared account

Correct Answer: C. Old access should be reviewed and unnecessary access removed

Question 8

What is the main accountability weakness of a shared account?

A. It increases password length

B. It makes individual actions difficult to attribute

C. It prevents all authorization decisions

D. It automatically creates excessive encryption

Correct Answer: B. It makes individual actions difficult to attribute

Question 9

Which statement best describes zero trust?

A. All internal network users are automatically trusted

B. Access is explicitly verified and limited rather than assumed from network location

C. Only passwords may be used for authentication

D. Users are never allowed to access cloud services

Correct Answer: B. Access is explicitly verified and limited rather than assumed from network location

Question 10

Which biometric measure represents the probability that an unauthorised person is accepted?

A. False rejection rate

B. False acceptance rate

C. Password entropy

D. Session timeout rate

Correct Answer: B. False acceptance rate