Cybersecurity Basics

Chapter 7
Identity and Access Management

Bachelors Program in Computer Science Engineering
Cybersecurity Basics   •   Bachelor

Identity and Access Management

Introduction

Identity and access management (IAM) is the discipline of ensuring that the right subjects obtain the right access to the right resources at the right time and for the right reasons. It is a central cybersecurity capability because most attacks ultimately attempt to misuse identity: an attacker may steal a password, exploit an overprivileged account, create a fraudulent identity, or retain access after an employee leaves.

IAM applies to human users, administrators, applications, devices, services, and automated processes. It supports confidentiality by restricting disclosure, integrity by preventing unauthorized modification, and availability by ensuring that legitimate users can access necessary services. IAM also contributes to accountability because actions can be associated with identifiable subjects and recorded for later review.

A useful IAM model follows four related activities:

  1. Identification: claiming an identity, such as entering a username.
  2. Authentication: proving control of that identity.
  3. Authorization: determining what an authenticated subject may do.
  4. Accounting: recording and reviewing access-related activity.

These activities are related but not interchangeable. Authentication does not itself grant permission, and authorization is not meaningful if identity evidence is unreliable.

Learning Objectives

After studying this chapter, students should be able to:

  • distinguish identification, authentication, authorization, and accounting;
  • explain authentication factors and evaluate multifactor authentication (MFA);
  • compare discretionary, mandatory, role-based, and attribute-based access control;
  • describe federation and single sign-on (SSO);
  • explain privileged access management and identity lifecycle management;
  • analyze IAM risks, controls, governance requirements, and ethical concerns;
  • design a basic IAM approach for an organizational scenario.

1. Identity, Subjects, Objects, and Policy

An identity is a recognized representation of an entity in a system. An entity may be a person, service, device, workload, or organization. A subject is an active entity requesting access. An object is a resource being accessed, such as a file, database record, application function, or network service.

Access decisions are governed by policy. In abstract form, a policy evaluates a request:

Decision = Policy(Subject, Action, Object, Context)

The decision may be permit, deny, or require an additional control. The subject might be a nurse, the action might be “read,” the object might be a patient record, and the context might include location, device trust, time, and risk level.

IAM therefore involves more than a login screen. It includes identity repositories, credential management, policy engines, directories, authentication services, authorization mechanisms, audit logs, governance processes, and administrative procedures.

Identification

Identification is the process by which a subject states an identity. Examples include a username, email address, employee number, certificate subject name, or service principal. Identification is an assertion, not proof. Two users may claim the same username, and an attacker may submit another person’s identifier.

Authentication

Authentication establishes confidence that the subject controls the claimed identity. Common evidence includes:

  • Knowledge factors: passwords, PINs, and memorized secrets.
  • Possession factors: hardware security keys, smart cards, and authenticator applications.
  • Inherence factors: fingerprints, facial characteristics, or voice patterns.
  • Location factors: geographic or network location. These are generally supplementary because location can be manipulated.
  • Behavioral factors: typing rhythm or interaction patterns. These are usually risk signals rather than sole authenticators.

A factor should represent a distinct category. Entering a password and answering a security question normally remains two knowledge factors, not true MFA. MFA requires two or more independent factor categories.

Authorization

Authorization determines whether an authenticated subject may perform a particular action on a particular object. Permissions should be specific enough to support business needs while limiting unnecessary capability. Typical actions include create, read, update, delete, execute, approve, and administer.

Authorization commonly follows the principles of least privilege, need to know, separation of duties, and default deny. Least privilege grants only the access required for assigned duties. Need to know limits access to information required for a task. Separation of duties divides sensitive activities among people or roles so that one person cannot complete an abusive transaction alone. Default deny means that access is refused unless an applicable rule permits it.

Accounting and Accountability

Accounting records relevant identity and access events. Typical records include login success and failure, password changes, privilege elevation, policy decisions, administrative actions, and logout or session expiration. Logs should contain a timestamp, subject, source, action, object or service, result, and a correlation identifier where possible.

Accounting supports accountability, incident response, compliance, and forensic investigation. However, a log is useful only if it is accurate, protected from tampering, retained appropriately, and reviewed. Time synchronization is particularly important when events from multiple systems must be reconstructed.

2. Authentication and Credential Security

Passwords and Secrets

Passwords remain common but are vulnerable to phishing, reuse, guessing, credential stuffing, and database compromise. Organizations should encourage long, unique passwords and use password managers where appropriate. Password databases must not store plaintext passwords. A verifier should store a salted, computationally expensive password hash using a current password-hashing design such as Argon2id, bcrypt, or scrypt, configured according to current guidance.

A salt is a unique random value stored with each password hash. It prevents identical passwords from producing identical stored values and makes large precomputed tables less effective. Hashing is not encryption: a password hash is designed to be difficult to reverse, whereas encrypted data is intended to be decrypted with a key.

Multifactor Authentication

MFA substantially reduces the value of a stolen password, especially when a phishing-resistant method is used. Hardware security keys and passkeys based on public-key cryptography are generally stronger against phishing than one-time codes entered into a web page. Time-based one-time passwords are useful but can still be phished. SMS codes provide some protection against password-only attacks but are exposed to risks such as number transfer fraud and interception; they should not be treated as the strongest available method.

MFA is not automatically secure. Attackers may use prompt bombing, social engineering, adversary-in-the-middle phishing, malicious recovery processes, or stolen session tokens. Effective deployment therefore includes number matching or other anti-fatigue controls, device binding, recovery protection, monitoring, and user education.

Biometrics

Biometric authentication uses a measured characteristic to verify or recognize a person. It is convenient and difficult to share casually, but biometric data is not a secret in the same sense as a password. A fingerprint cannot normally be changed after compromise. Biometric systems also have false acceptance and false rejection errors, environmental limitations, demographic performance differences, and privacy implications.

A biometric system must balance two important error rates:

  • False acceptance rate (FAR): the probability that an unauthorized person is accepted.
  • False rejection rate (FRR): the probability that an authorized person is rejected.

Changing the decision threshold generally affects both rates. Biometrics are often best used as a local unlock factor for a protected device or cryptographic key, rather than as a centrally stored replacement for all other authentication methods.

3. Access-Control Models

Access-control models differ in who defines permissions and which properties determine a decision.

ModelMain decision basisTypical strengthTypical limitation
Discretionary access control (DAC)Resource owner or creatorFlexible and easy to delegatePermissions may spread unpredictably
Mandatory access control (MAC)Central policy using labels or classificationsStrong, consistent enforcementLess flexible and administratively demanding
Role-based access control (RBAC)Organizational roleManageable for stable job functionsRole explosion or stale roles
Attribute-based access control (ABAC)Attributes and policy rulesFine-grained, context-aware decisionsComplex policy design and governance

Discretionary Access Control

In DAC, an owner controls access to an object. A file owner may grant another user read or write permission. Access control lists (ACLs) are a common implementation. DAC is practical for collaborative environments, but users may unintentionally grant excessive access, and permissions can become difficult to audit as objects and relationships multiply.

Mandatory Access Control

MAC uses centrally managed labels, such as “confidential” or “restricted,” and rules that govern how subjects and objects interact. In a military-style model, a subject’s clearance and an object’s classification are compared. Users cannot normally override the central policy. MAC can provide strong containment, but classification accuracy, administration, and legitimate information sharing can be challenging.

Role-Based Access Control

RBAC assigns permissions to roles and assigns users to roles. For example, a “payroll clerk” role may read payroll data and create payroll entries but may not approve payroll. RBAC reduces direct user-permission administration and aligns access with organizational responsibilities.

RBAC requires careful role engineering. Excessively broad roles violate least privilege; excessively narrow roles create role explosion. Role hierarchies can represent senior responsibilities, but inherited permissions must be reviewed carefully. Temporary or project-based roles should have expiration dates.

Attribute-Based Access Control

ABAC evaluates attributes of the subject, object, action, and environment. A policy might allow a clinician to read a patient record when the clinician is assigned to that patient, the purpose is treatment, the device is managed, and the request occurs during an authorized session.

ABAC is well suited to cloud, zero-trust, and distributed environments because context can change continuously. It also creates policy complexity. Attributes must be trustworthy, understandable, current, and protected against manipulation. ABAC policies should be tested for conflicts, unintended combinations, and fail-safe behavior.

Comparing the Models

These models are not always mutually exclusive. An organization may use RBAC for baseline employment permissions, ABAC for device and location conditions, and MAC-like labels for highly sensitive information. A mature architecture selects the model or combination that matches business processes, regulatory requirements, technical capability, and risk.

4. Federation and Single Sign-On

Identity federation allows one organization or identity provider (IdP) to provide authentication information to another organization or service provider (SP). Instead of each application maintaining an independent password database, the application trusts assertions or tokens issued by the IdP.

Common federation technologies include Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0. OIDC provides an authentication layer over OAuth 2.0 and uses signed tokens to communicate identity claims. OAuth 2.0 primarily addresses delegated authorization, not authentication by itself.

Single sign-on allows a user to authenticate once and access multiple trusted services without independently logging in to each one. SSO improves usability and can centralize MFA, account disablement, and policy enforcement. It also creates concentration risk: compromise of the IdP or a high-value session may affect many services.

Federation requires trust management. Organizations must validate issuer identity, token audience, signature, time validity, scopes, redirect locations, and claims. They must also plan for key rotation, provider outage, account linking errors, and emergency revocation. SSO does not eliminate authorization; each service must still enforce appropriate permissions.

5. Privileged Access Management

A privileged account can change configurations, access sensitive data, create identities, disable controls, or affect many systems. Examples include domain administrators, database administrators, cloud root users, security operators, and service accounts with broad permissions.

Privileged access management (PAM) reduces the risk associated with these accounts through:

  • separate administrative and ordinary user accounts;
  • just-in-time or time-limited elevation;
  • approval workflows for high-risk actions;
  • credential vaulting and automatic rotation;
  • session recording and command monitoring where lawful and appropriate;
  • restrictions on direct use of shared or permanent administrator credentials;
  • emergency or “break-glass” accounts with strong protection and review;
  • alerting on unusual administrative behavior.

PAM must not become a single point of failure. Vaults and emergency processes require redundancy, tested recovery, and carefully controlled access. Service accounts should have documented owners, narrowly scoped permissions, managed secrets, and a replacement plan for long-lived credentials.

6. Identity Lifecycle Management

Identity lifecycle management governs identities from creation to removal. The principal stages are:

  1. Joiner: verify the person or system, create the identity, assign baseline access, and issue credentials.
  2. Mover: modify access when duties, department, location, or project changes.
  3. Leaver: disable accounts, revoke sessions and credentials, recover devices, and preserve necessary records.
  4. Periodic review: confirm that access remains appropriate and remove unnecessary permissions.

A robust process integrates human-resources, student, contractor, asset, and service-management systems. Provisioning should be based on authoritative data rather than informal email requests. Deprovisioning should be prompt, especially for privileged access. Orphaned accounts, dormant accounts, duplicate identities, and unmanaged service identities are significant risks.

Access certification asks a responsible manager or data owner to confirm that access remains justified. Certification is ineffective if reviewers receive confusing lists, cannot understand permissions, or approve automatically. Meaningful review requires ownership, evidence of use, clear descriptions, and escalation of exceptions.

7. IAM Governance, Risk, and Compliance

IAM governance defines who may request, approve, grant, review, and revoke access. Important governance questions include:

  • Who owns each application and data set?
  • Which access requires independent approval?
  • How are exceptions documented and expired?
  • What evidence demonstrates that access reviews occurred?
  • How are access events monitored and investigated?
  • How are privacy rights and retention requirements satisfied?

IAM controls should be risk-based. A public information portal and a financial reporting system do not require identical controls. High-risk access may require phishing-resistant MFA, dual approval, device compliance, privileged session monitoring, and shorter review intervals.

IAM also interacts with privacy and data protection. Organizations should collect only identity data needed for a legitimate purpose, protect biometric and behavioral data, restrict administrative visibility, establish retention periods, and provide transparent notice. Excessive monitoring can undermine employee autonomy and trust. Security objectives must be balanced with proportionality, fairness, accessibility, and due process.

8. Applied Case: University Research and Administration Platform

Background

This illustrative case concerns a university that operates student records, payroll, research systems, laboratory devices, and cloud collaboration services. Users include students, faculty, administrative staff, visiting researchers, contractors, and automated services.

Problem

The university has separate passwords for many applications. Former students retain access to collaboration systems, research assistants receive broad shared-drive permissions, and administrators use permanent high-privilege accounts. Audit logs are inconsistent, and a phishing incident compromises several passwords.

Analysis

The main weaknesses are fragmented identity stores, delayed deprovisioning, excessive permissions, weak privileged-account separation, and limited visibility. Simply adding another login screen would not solve the authorization and lifecycle problems.

Approach and Solution

The university establishes a central IdP and federates suitable applications through SAML or OIDC. Students and employees use SSO with phishing-resistant MFA where feasible. The authoritative student and human-resources systems drive joiner, mover, and leaver events.

Baseline access is assigned through RBAC: students receive student services, faculty receive teaching services, and payroll staff receive payroll functions. ABAC conditions restrict sensitive records based on department, assignment, device status, and purpose. Research data uses project-specific groups with expiration dates. Data owners approve access, and quarterly reviews focus on high-risk permissions.

Administrators receive separate accounts and request just-in-time elevation through PAM. Cloud and service accounts use short-lived credentials where possible. Central logging records authentication, federation, privilege elevation, and important authorization events. Security staff monitor unusual sign-ins, impossible travel indicators, repeated MFA failures, and unexpected administrative actions.

Outcome

The university reduces password reuse, improves termination processing, limits standing privilege, and gains a consistent audit trail. Some legacy applications cannot immediately support federation, so they are isolated, monitored, and placed on a replacement roadmap. The implementation also includes accessibility testing and recovery procedures for users who lose their authentication device.

Learning Points

The case demonstrates that IAM is an organizational system rather than a single product. SSO and MFA improve authentication, but lifecycle automation, authorization design, privileged-access controls, governance, logging, and recovery are equally necessary.

9. Challenges and Contemporary Developments

Cloud computing and software-defined infrastructure have increased the number of non-human identities. Application programming interfaces, containers, serverless functions, and robotic processes may each require credentials. These identities need ownership, scoped permissions, rotation, monitoring, and lifecycle events just like human identities.

Zero-trust architectures treat access as continuously evaluated rather than permanently trusted because of network location. Identity, device posture, workload integrity, resource sensitivity, and session risk may all influence a decision. Zero trust is not a single product and does not mean that every request is rejected; it means that access is explicitly verified and appropriately limited.

Passkeys and WebAuthn-style authentication use public-key cryptography and can resist many forms of phishing because the credential is bound to the legitimate origin. Organizations must still manage device loss, recovery, account recovery attacks, accessibility, and interoperability.

Artificial intelligence can assist IAM by detecting anomalous sign-ins, prioritizing access-review items, identifying privilege accumulation, and correlating identity events. However, automated decisions may produce false positives, embed bias, expose sensitive data, or be difficult to explain. AI should support—not replace—clear policy, human oversight, appeal mechanisms, and evidence-based investigation.

Common implementation failures include treating compliance checklists as security, deploying MFA without protecting recovery, granting broad roles for convenience, ignoring service accounts, failing to test revocation, and collecting excessive personal information. Successful IAM programs begin with authoritative identity data, explicit ownership, measurable policies, secure defaults, tested operations, and continuous improvement.

Chapter Summary

Identity and access management connects identification, authentication, authorization, and accounting into a governance and technology discipline. Identification asserts an identity; authentication verifies it; authorization determines permitted actions; and accounting records activity for accountability and investigation. Strong IAM uses least privilege, need to know, separation of duties, default deny, secure credential handling, and appropriate MFA.

DAC emphasizes owner discretion, MAC relies on centrally enforced labels, RBAC maps permissions to job roles, and ABAC evaluates subject, object, action, and environmental attributes. Federation and SSO centralize authentication but do not remove the need for service-level authorization. PAM limits the risks of powerful accounts through separation, time-limited elevation, vaulting, monitoring, and review. Identity lifecycle management ensures that access is created, changed, reviewed, and removed as organizational status changes.

Effective IAM is simultaneously technical, procedural, legal, and ethical. It must address human and non-human identities, cloud services, privacy, recovery, auditability, accessibility, and emerging capabilities such as passkeys and AI-assisted detection.

Key Terms

Identity: A recognized representation of an entity in a system.

Subject: An entity that requests or performs an action.

Object: A resource upon which an action is performed.

Identification: The act of claiming an identity.

Authentication: Verification of control over a claimed identity.

Authorization: Determination of permitted actions on resources.

Accounting: Recording and reviewing identity and access activity.

MFA: Authentication using two or more independent factor categories.

Biometrics: Authentication or recognition based on measurable human characteristics.

DAC: Access control in which an owner commonly determines permissions.

MAC: Centrally enforced access control based on policy and labels.

RBAC: Access control based on organizational roles.

ABAC: Access control based on attributes and policy rules.

Federation: Trust between identity and service providers for identity information.

SSO: A capability allowing access to multiple trusted services after one authentication.

PAM: Controls for managing and monitoring privileged access.

Least privilege: Granting only the permissions required for a task.

Identity lifecycle: The creation, modification, review, and removal of identities and access.

Phishing-resistant authentication: Authentication designed to prevent credentials being reused at a fraudulent site.

Review Questions

5 Short Answer Questions

  1. Distinguish identification from authentication.
  2. Why is authorization still necessary after successful authentication?
  3. What makes two authentication methods genuine MFA rather than two instances of one factor?
  4. State two advantages and one limitation of RBAC.
  5. Why should privileged administrators use separate accounts?

5 Long Answer Questions

  1. Explain the four activities of IAM and show how they support confidentiality, integrity, and accountability.
  2. Compare DAC, MAC, RBAC, and ABAC, including an appropriate use case and limitation for each.
  3. Discuss the security and operational benefits and risks of federation and SSO.
  4. Describe a complete joiner–mover–leaver lifecycle process for a university or business.
  5. Explain how PAM, least privilege, separation of duties, and access reviews work together.

3 Analytical / Application Questions

  1. A hospital wants clinicians to access patient records only when assigned to the patient, using a managed device during an active treatment session. Which access-control model or combination would you recommend, and what attributes would the policy evaluate?
  2. An employee leaves an organization but retains an active cloud session for two days. Analyze the lifecycle and technical control failures, and propose corrective measures.
  3. Design an IAM architecture for a small cloud-based company with employees, contractors, administrators, and automated services. Justify your choices of authentication, federation, authorization, PAM, logging, and review controls.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a subject controls a claimed identity?

A. Identification

B. Authentication

C. Authorization

D. Accounting

Correct Answer: B. Authentication

Question 2

Which example best represents a possession factor?

A. A password

B. A fingerprint

C. A hardware security key

D. A security question

Correct Answer: C. A hardware security key

Question 3

In role-based access control, permissions are primarily assigned to:

A. Network locations

B. Organizational roles

C. Individual passwords

D. Encryption algorithms

Correct Answer: B. Organizational roles

Question 4

Which model evaluates subject, object, action, and environmental attributes?

A. DAC

B. MAC

C. RBAC

D. ABAC

Correct Answer: D. ABAC

Question 5

What is a major risk of permanent administrator accounts?

A. They prevent all logging

B. They increase the impact of credential compromise

C. They eliminate the need for authorization

D. They require biometric storage

Correct Answer: B. They increase the impact of credential compromise

Question 6

Which statement about OAuth 2.0 is most accurate?

A. It is primarily a delegated authorization framework

B. It is a password-hashing algorithm

C. It is a mandatory access-control model

D. It is a biometric standard

Correct Answer: A. It is primarily a delegated authorization framework

Question 7

What is the principal purpose of a unique password salt?

A. To decrypt the password

B. To make identical passwords produce identical hashes

C. To reduce the effectiveness of precomputed hash tables

D. To replace multifactor authentication

Correct Answer: C. To reduce the effectiveness of precomputed hash tables

Question 8

Which lifecycle event normally requires access to be revoked?

A. A user changes their desk location

B. An employee leaves the organization

C. A user opens a help-desk ticket

D. A manager reviews a policy

Correct Answer: B. An employee leaves the organization

Question 9

Which authentication method is generally most resistant to ordinary phishing?

A. A password alone

B. An SMS code entered into any website

C. A hardware security key using origin-bound public-key authentication

D. A reusable security question

Correct Answer: C. A hardware security key using origin-bound public-key authentication

Question 10

What is the main purpose of accounting in IAM?

A. To create job roles

B. To record and review access-related activity

C. To classify biometric characteristics

D. To replace authorization policies

Correct Answer: B. To record and review access-related activity

Cybersecurity Basics
Chapter 7 of 15