Identity and Access Management

Introduction

Identity and Access Management (IAM) is the organizational capability used to establish digital identities, authenticate users and services, authorize access, monitor activity, and remove access when it is no longer justified. In a data-driven organization, IAM protects data not merely by placing controls around networks or databases, but by continuously answering four questions:

1. Who or what is requesting access?
2. Can the identity be reliably authenticated?
3. What is the requester allowed to do?
4. Is the access still appropriate for the current context and business purpose?

IAM is therefore both a technical discipline and a governance process. It includes directories, authentication services, authorization models, identity lifecycle management, service-account controls, privileged access management (PAM), segregation of duties (SoD), access reviews, and identity governance and administration (IGA).

A mature IAM program follows the principles of least privilege, need-to-know, accountability, separation of duties, default denial, risk-based control, and timely removal of obsolete access. These principles are especially important in data science environments, where analysts, engineers, notebooks, pipelines, cloud workloads, APIs, and machine-learning platforms may all access sensitive datasets.

Learning Objectives

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

• Explain the purpose and architecture of IAM.
• Design an identity lifecycle covering joining, movement, suspension, and departure.
• Distinguish authentication, authorization, accounting, and federation.
• Compare directory services and authorization models.
• Govern human, service, machine, and privileged accounts.
• Apply least privilege, SoD, access reviews, and risk-based governance.
• Evaluate IAM technologies, implementation risks, and ethical implications.
• Design an IAM operating model for a data-intensive organization.

1. IAM Foundations

1.1 Identity, account, credential, and entitlement

An identity is a recognized representation of a person, service, device, or other actor. An account is a technical object through which an identity interacts with a system. A credential is evidence used to authenticate an identity, such as a password, cryptographic key, certificate, hardware token, or biometric factor. An entitlement is a permission or access right, such as read access to a data lake or the ability to approve a payment.

These concepts must not be conflated. One person may have several accounts, while one service identity may operate without a human owner. An account may remain active after an employee has left unless lifecycle controls explicitly disable it. IAM seeks to maintain a trustworthy relationship between the authoritative identity record, technical accounts, credentials, and entitlements.

1.2 Authentication, authorization, and accountability

Authentication establishes identity. Authorization determines permitted actions. Accounting, often called auditing or accountability, records what occurred and supports investigation. A useful conceptual sequence is:

Identity claim → authentication → policy evaluation → authorization decision → monitored action.

Authentication factors are commonly classified as:

• Something known: password or personal identification number.
• Something possessed: hardware token or authenticator application.
• Something inherent: biometric characteristic.
• Somewhere the user is or something the user does: contextual and behavioral signals.

Multi-factor authentication (MFA) combines independent factors. Two passwords are not normally two independent factors because both are knowledge factors. MFA reduces the impact of stolen passwords but does not eliminate phishing, session theft, compromised devices, or authorization errors.

1.3 Identification and federation

Single sign-on (SSO) allows a user to authenticate once and access multiple relying applications. Federated identity allows an identity provider (IdP) to issue assertions or tokens accepted by service providers. Common protocols include SAML, OAuth 2.0, and OpenID Connect. OAuth 2.0 primarily provides delegated authorization; OpenID Connect adds an identity layer on top of OAuth 2.0.

Federation reduces duplicated passwords and centralizes policy, but it creates concentration risk. A compromised IdP can affect many applications. Consequently, organizations require strong IdP protection, resilient recovery, token validation, careful redirect configuration, secure key management, and clear ownership of claims and authorization decisions.

2. Identity Lifecycle Management

Identity lifecycle management governs the complete existence of an identity, from registration to archival. The lifecycle should be event-driven, documented, measurable, and connected to authoritative sources such as human resources, student records, vendor management, or asset-management systems.

2.1 Joiner, mover, leaver, and exceptional events

The standard lifecycle is often described as:

• Joiner: a new employee, student, contractor, partner, or service is registered and receives approved baseline access.
• Mover: a role, department, location, project, employment status, or risk classification changes. Access is recalculated rather than simply accumulated.
• Leaver: employment, contract, affiliation, or service purpose ends. Access and credentials are disabled or revoked promptly.
• Exceptional event: suspension, investigation, extended leave, account compromise, emergency access, or organizational restructuring requires accelerated action.

A strong process defines an owner, an authoritative trigger, a service-level target, approval rules, evidence requirements, and reconciliation controls for every lifecycle event.

2.2 Provisioning and modification

Provisioning may be manual, automated, or hybrid. A typical automated flow is:

1. An authoritative source creates or changes the identity record.
2. An identity governance platform evaluates role and policy rules.
3. Required approvals are obtained for nonstandard access.
4. Connectors create or modify accounts in directories and applications.
5. The platform records the request, decision, implementation result, and exceptions.
6. Reconciliation detects failed or unauthorized changes.

The birthright access principle gives every identity only the minimum access required for basic functioning, such as email or a learning platform. Additional access should be role-based, attribute-based, project-based, or individually approved.

Modification is more difficult than initial provisioning because access tends to accumulate. A mover process must compare old and new access, remove incompatible entitlements, transfer ownership of resources, and prevent a role change from leaving dormant privileges behind.

2.3 De-provisioning

De-provisioning includes disabling authentication, revoking sessions and tokens, removing group memberships, disabling application accounts, rotating shared secrets, transferring data ownership, and recovering organizational assets. Disabling a central directory account alone is insufficient if applications maintain independent accounts or long-lived API keys.

A practical design uses risk tiers. For example, privileged accounts and access to regulated data may be disabled immediately on a confirmed departure, while low-risk archival access may follow a documented schedule. The exact time target depends on legal, operational, and risk requirements; it should not be assumed that one universal period fits all organizations.

2.4 Lifecycle controls and metrics

Useful metrics include:

• Percentage of joiner and leaver events completed within target time.
• Number and age of orphaned accounts.
• Number of dormant accounts.
• Percentage of entitlements with a named owner.
• Access-review completion and overdue rates.
• Privileged sessions using approved controls.
• Number of policy exceptions and average exception age.

Metrics must be interpreted carefully. A high completion rate may conceal poor review quality, inaccurate source data, or unmeasured application accounts. Effectiveness should therefore combine quantitative indicators with sampling, audit evidence, incident findings, and user feedback.

3. Directories and Identity Architecture

A directory service stores and retrieves identity and organizational information. It may contain users, groups, devices, service identities, certificates, and attributes. Directories support authentication, group-based authorization, address services, and synchronization.

A reference architecture normally includes:

• Authoritative sources, such as HR and vendor systems.
• An IGA platform for requests, approvals, policies, certification, and provisioning.
• One or more directories or identity providers.
• Application connectors and APIs.
• Authentication and MFA services.
• Privileged-access infrastructure.
• Logging, security monitoring, and reporting.

Directories should use unique immutable identifiers rather than relying only on names or email addresses. Naming collisions, reused identifiers, duplicate records, and inconsistent attributes create serious authorization risks. Attribute quality is especially important in attribute-based access control (ABAC).

Directory synchronization must be governed. A synchronization error can replicate incorrect group membership across many systems. Controls include schema validation, change monitoring, reconciliation, protected administrator accounts, secure transport, and separation between authoritative write systems and read replicas.

4. Authorization Models

4.1 Role-based access control

In role-based access control (RBAC), permissions are assigned to roles and users receive roles according to job function. RBAC simplifies administration and supports SoD analysis, but poorly designed roles can become excessively broad or numerous.

A role should have a business owner, documented purpose, entitlement list, eligibility rules, approval authority, review frequency, and retirement criteria. Technical groups should not automatically be treated as business roles without analysis.

4.2 Attribute-based and policy-based access control

ABAC evaluates attributes of the subject, resource, action, and environment. For example, a policy may permit a researcher to read de-identified data when the researcher is assigned to the approved project, the request originates from a managed device, and the dataset classification permits the action.

ABAC provides contextual precision but depends on accurate attributes, understandable policies, reliable enforcement points, and strong testing. A policy that appears restrictive may become permissive if an attribute is missing and the system interprets missing information as true.

Policy-based access control generalizes this approach by using centrally managed policies and policy decision points. Policy enforcement points must fail safely, log decisions, and remain available enough for business continuity.

4.3 Least privilege and zero trust

Least privilege grants only the access necessary for an authorized purpose and period. It applies to humans, applications, pipelines, containers, and administrators. Zero trust is a broader security approach in which access is not automatically trusted because of network location or prior authentication. Decisions consider identity, device posture, resource sensitivity, session risk, and context.

Least privilege is not equivalent to denying all access. Excessive restriction may cause unsafe workarounds, shared accounts, or uncontrolled data copies. Effective least privilege is therefore iterative: measure actual use, remove unnecessary rights, test business impact, and introduce time-bound elevation where needed.

5. Service and Machine Identities

Service accounts support applications, scheduled jobs, databases, integration platforms, containers, and data pipelines. They are frequently neglected because they do not correspond to employees, yet they can possess extensive and persistent access.

Every service identity should have:

• A named business and technical owner.
• A documented purpose and data-flow context.
• A unique identity rather than a shared human account.
• Minimum required permissions.
• Secrets stored in a protected vault or replaced by short-lived credentials.
• Rotation, expiry, and recovery procedures.
• Monitoring and alerting for unusual use.
• A defined retirement condition.

Static passwords embedded in source code, notebooks, configuration files, or container images are high-risk. Workload identity, managed identities, certificates, and short-lived tokens can reduce exposure. However, automation does not remove accountability: ownership, authorization, logging, and emergency recovery remain necessary.

A service identity should not be used interactively by a human. Where administrative intervention is necessary, a controlled elevation process should issue temporary credentials and record the operator, reason, duration, commands, and outcome.

6. Privileged Access Management

Privileged access can alter security controls, identities, infrastructure, code, data, or audit records. PAM reduces the risk associated with such access through technical and procedural controls.

Core PAM capabilities include:

• Discovery and inventory of privileged accounts.
• Separate administrative accounts for administrators.
• MFA and strong authentication.
• Just-in-time or time-bound elevation.
• Approval and business justification.
• Password or secret vaulting and rotation.
• Session recording and command logging where lawful and proportionate.
• Emergency or break-glass access with retrospective review.
• Removal of standing privileges.

PAM should cover cloud consoles, database administrators, domain administrators, CI/CD pipelines, infrastructure-as-code systems, and machine identities. Session recording creates privacy and storage responsibilities, so access to recordings must itself be restricted and retention must be justified.

7. Segregation of Duties

SoD prevents one individual or identity from controlling incompatible stages of a sensitive process. For example, the same person should generally not create a supplier, approve a payment, and reconcile the payment. In a data environment, a developer may be prohibited from independently deploying code to production and approving the production change.

SoD can be represented through:

• Mutually exclusive roles: two roles cannot be assigned together.
• Conflicting entitlements: particular permissions cannot coexist.
• Sequential controls: one person may perform a task, but a different person must approve the next stage.
• Compensating controls: where staffing makes strict separation impossible, independent review, enhanced logging, and retrospective approval reduce risk.

SoD analysis must distinguish genuine conflict from merely similar permissions. It should consider actual business processes, emergency procedures, temporary assignments, and service identities. A conflict report with thousands of technically possible combinations may be less useful than a smaller set of risk-ranked, business-validated rules.

8. Access Reviews and Identity Governance

An access review, or access certification, asks an accountable reviewer whether access remains appropriate. It is not merely an administrative confirmation. A meaningful review displays the identity, entitlement, resource sensitivity, business justification, last-use information where reliable, and consequences of approval.

Review types include:

• Manager review of employee access.
• Application-owner review of application entitlements.
• Data-owner review of sensitive datasets.
• Privileged-access review.
• SoD conflict review.
• Dormant and orphan-account review.

Reviewers need sufficient context and must be accountable for decisions. “Approve all” interfaces encourage rubber-stamping. Better designs group low-risk birthright access, highlight unusual or unused privileges, require reasons for high-risk approval, and escalate overdue reviews.

Identity governance and administration (IGA) integrates request management, approval workflows, provisioning, certification, policy enforcement, reporting, and audit evidence. IGA does not replace directory security or application authorization; it coordinates governance across them.

A sound governance operating model assigns:

• Identity owners for the identity record.
• Application owners for application access.
• Data owners for data permissions.
• Managers for employment-related access decisions.
• Security teams for policy and control oversight.
• Internal audit or risk functions for independent assurance.

9. Designing an IAM Program

IAM design should begin with business processes and risk, not with product selection. A structured method is:

1. Identify identities, applications, data stores, infrastructure, and trust relationships.
2. Classify data and identify high-impact operations.
3. Establish authoritative identity sources.
4. Define lifecycle events and ownership.
5. Select authorization patterns appropriate to the environment.
6. Design privileged and service-identity controls.
7. Define SoD rules and exception handling.
8. Implement access reviews and evidence retention.
9. Integrate monitoring, incident response, and business continuity.
10. Measure effectiveness and improve continuously.

A risk-based prioritization model can consider impact, likelihood, exposure, and control strength, but organizations should avoid false precision. Scores are decision aids, not objective measurements. High-priority work commonly includes privileged accounts, sensitive data platforms, externally accessible applications, orphaned accounts, and systems with independent credentials.

Worked design example

A research organization has 600 employees, 80 contractors, a cloud data lake, a model registry, a production analytics platform, and 1,200 service identities. The initial assessment finds that contractors are provisioned manually, 14% of service accounts have no named owner, and leavers retain access to one legacy application for several days.

A suitable improvement plan is:

• Use the contractor-management system as the authoritative source for contractor status.
• Provide baseline access through lifecycle rules and route sensitive project access through approval.
• Link the leaver event to immediate directory disablement and application reconciliation.
• Inventory service identities and require a named owner, purpose, expiry review, vault-managed secret, and minimum permissions.
• Place production administration behind MFA, separate administrator accounts, and time-bound PAM elevation.
• Define conflicting roles for model development, production deployment, and production approval.
• Conduct quarterly high-risk reviews and semiannual reviews for ordinary application access.
• Monitor failed provisioning, unowned accounts, review exceptions, and privileged sessions.

The design addresses both human and non-human identities and recognizes that automation must be accompanied by reconciliation and ownership.

10. Illustrative Case Study: Northbridge Health Analytics

Background

Northbridge Health Analytics, a fictional organization, provides predictive services to hospitals. It operates a cloud data lake containing identifiable and de-identified health information. Data scientists access notebooks, engineers operate pipelines, and external researchers receive project-based access.

Problem

An audit discovers shared analyst accounts, long-lived cloud keys in scripts, inconsistent termination procedures, and reviewers who approve access without seeing data classification. A former contractor’s account remains active in a research workspace.

Analysis

The central weakness is not only authentication. Northbridge lacks authoritative ownership and lifecycle integration. Shared accounts prevent individual accountability, while static keys and delayed termination create persistent access paths. Reviews are formal but not risk-informed. The organization also has an SoD conflict: a developer can deploy a model and approve its production release.

Approach and solution

Northbridge establishes a central IdP with MFA and federation, prohibits shared human accounts, and assigns project roles through IGA workflows. The contractor system becomes the authoritative source for status. Cloud workload identities replace embedded keys where possible; remaining secrets are placed in a vault with rotation and monitoring.

PAM is introduced for production administration, with separate administrative identities, just-in-time elevation, approval, and session logging. Data owners classify datasets and approve access based on project purpose. Model developers may submit releases, but production approval is assigned to an independent operations or model-risk role. Quarterly certifications focus on sensitive data, privileged access, and external researchers.

Outcome

The organization reduces orphaned accounts, improves evidence for audits, and can attribute administrative actions to individuals. Researchers retain necessary access, but access is limited to approved projects and reviewed at defined intervals. The case also demonstrates that IAM is a socio-technical system: technology succeeds only when ownership, process, training, and incentives are aligned.

Learning points

• Identity lifecycle integration is more reliable than isolated manual checklists.
• Service identities require governance equal to human identities.
• Access reviews must provide evidence and context.
• SoD should reflect real business risk rather than only technical group combinations.
• Privacy, usability, and operational continuity must be considered alongside security.

11. Governance, Ethics, and Regulation

IAM processes handle personal data, employment information, behavioral logs, and sometimes biometrics. Organizations should apply purpose limitation, data minimization, retention limits, transparency, and access controls to IAM data itself. Behavioral monitoring and session recording should be proportionate, legally reviewed, and communicated to affected people.

Regulatory obligations vary by jurisdiction and sector, but common expectations include unique user identification, least privilege, strong authentication for sensitive access, timely termination, audit trails, periodic review, and evidence of control operation. Compliance should not be treated as a substitute for risk analysis. A control can satisfy a checklist while failing operationally.

Ethical questions include whether automated risk scoring unfairly restricts certain groups, whether access decisions are explainable, and whether identity data is retained longer than necessary. Accessibility must also be considered: authentication controls should support users with disabilities and avoid excluding legitimate users without a safe recovery path.

12. Contemporary Developments and Limitations

Cloud-native and multi-cloud environments increase the number of identities and authorization planes. Infrastructure-as-code, ephemeral workloads, APIs, containers, and software supply chains require machine-readable policy and continuous reconciliation. Passkeys and phishing-resistant authentication can reduce dependence on passwords, but enrollment, recovery, device loss, and federation risks remain.

Artificial intelligence can assist with entitlement classification, anomalous-access detection, role mining, and review prioritization. It should not independently grant high-impact access without accountable policy owners and human oversight. Models may infer sensitive attributes, produce false positives, or encode historical bias. AI recommendations must be explainable enough for review, tested against representative data, and subject to appeal and correction.

Common IAM limitations include incomplete inventories, inaccurate attributes, legacy applications, excessive role complexity, weak ownership, alert fatigue, and resistance from users who experience controls as obstacles. Mature programs address these limitations through phased implementation, usability testing, exception governance, reconciliation, and continuous measurement.

Best-Practice Checklist

• Maintain an authoritative identity source and unique immutable identifiers.
• Automate joiner, mover, and leaver events, but reconcile outcomes.
• Use MFA, preferably phishing-resistant methods, for sensitive access.
• Separate human, service, device, and privileged identities.
• Apply least privilege and time-bound elevation.
• Prohibit shared accounts except where technically unavoidable and specially controlled.
• Assign owners and expiry or review dates to service identities and entitlements.
• Implement SoD rules based on real business processes.
• Make access reviews contextual, risk-based, and auditable.
• Protect the IdP, directories, secrets, logs, and recovery mechanisms.
• Integrate IAM with incident response and business continuity.
• Assess privacy, accessibility, fairness, and regulatory obligations.

Chapter Summary

IAM is a governance and technology discipline that connects trusted identities to justified access. Its central processes include authentication, authorization, accountability, federation, lifecycle management, directories, service-account governance, PAM, SoD, access certification, and IGA. Effective lifecycle design begins with authoritative sources and manages joiner, mover, leaver, and exceptional events. Directories and federation improve consistency but create concentration and synchronization risks. RBAC supports manageable job-function access, while ABAC and policy-based approaches provide contextual precision when attributes are reliable.

Service and privileged identities require explicit ownership, strong authentication, vaulting, monitoring, and time-bound access. SoD reduces the risk of unilateral misuse, and access reviews provide continuing assurance only when reviewers receive meaningful context. A mature IAM program is risk-based, measurable, privacy-aware, and integrated with incident response. Technology, including AI, can improve scale and detection, but cannot replace accountable governance and sound business processes.

Key Terms

Identity: A recognized representation of a person, service, device, or actor.

Account: A technical object used by an identity to access a system.

Credential: Evidence used to authenticate an identity.

Authentication: Verification of an identity claim.

Authorization: Determination of permitted actions or resources.

Accounting: Recording and attributing actions for accountability.

Federation: Trust relationship allowing identities from one domain to access another.

Single sign-on: Authentication mechanism enabling access to multiple services.

Directory service: Repository and service for identity and organizational information.

Identity lifecycle: Processes governing an identity from creation through retirement.

Provisioning: Creating or granting accounts and access.

De-provisioning: Removing or disabling accounts, credentials, and entitlements.

RBAC: Authorization based on organizational roles.

ABAC: Authorization based on subject, resource, action, and environmental attributes.

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

Service identity: Non-human identity used by software or workloads.

Privileged access management: Controls for high-impact administrative access.

Segregation of duties: Separation of incompatible responsibilities.

Identity governance and administration: Governance workflows for identity, access, approvals, reviews, and evidence.

Access certification: Formal review of whether existing access remains appropriate.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What are joiner, mover, and leaver events?
3. Why should service identities have named owners?
4. State two objectives of privileged access management.
5. What is the purpose of an access certification?

Long Answer Questions

1. Explain how an organization should design an end-to-end identity lifecycle process.
2. Compare RBAC and ABAC, including the conditions under which each is most useful.
3. Discuss the governance risks of service accounts and propose suitable controls.
4. Explain how PAM and segregation of duties reduce the risk of privileged misuse.
5. Design an IGA operating model for a cloud-based data science organization.

Analytical / Application Questions

1. A contractor changes from a low-risk analytics project to a project involving identifiable health data. Analyze the lifecycle, approval, and review actions required.
2. An organization has 3,000 technical groups and frequent SoD conflicts. Propose a method for rationalizing roles and prioritizing conflicts.
3. A machine-learning system recommends removing access based on unusual behavior. Evaluate the security, privacy, fairness, and governance controls required before automation is used in production.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication assigns roles, while authorization stores audit logs.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication removes accounts, while authorization creates credentials.

D. Authentication encrypts data, while authorization backs up directories.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

Which event should normally trigger removal or disabling of unnecessary access?

A. A routine password change

B. A successful access review

C. A confirmed employment or contract termination

D. A new directory replication cycle

Correct Answer: C. A confirmed employment or contract termination

Question 3

Which control most directly reduces the risk of secrets embedded in application code?

A. Using a shared administrator password

B. Storing secrets in a protected vault or using workload identity

C. Disabling audit logging

D. Assigning all applications the same service account

Correct Answer: B. Storing secrets in a protected vault or using workload identity

Question 4

What is the primary purpose of segregation of duties?

A. To ensure that one person controls an entire sensitive process

B. To prevent incompatible responsibilities from being concentrated in one identity

C. To eliminate the need for access reviews

D. To provide anonymous access to public data

Correct Answer: B. To prevent incompatible responsibilities from being concentrated in one identity

Question 5

Which feature is most characteristic of privileged access management?

A. Permanent administrator access for all developers

B. Time-bound elevation with approval and monitoring

C. Unlogged use of shared accounts

D. Disabling multi-factor authentication for operators

Correct Answer: B. Time-bound elevation with approval and monitoring

Question 6

Which authorization model evaluates attributes of the subject, resource, action, and environment?

A. ABAC

B. Simple password authentication

C. Static network segmentation

D. Manual account naming

Correct Answer: A. ABAC

Question 7

Why is reconciliation important in automated provisioning?

A. It guarantees that no policy is ever needed.

B. It detects failed, incomplete, or unauthorized changes in target systems.

C. It replaces the authoritative identity source.

D. It makes all users administrators.

Correct Answer: B. It detects failed, incomplete, or unauthorized changes in target systems.

Question 8

Which practice makes an access review more meaningful?

A. Showing reviewers only a list of usernames

B. Allowing automatic approval of all entitlements

C. Providing business justification, resource sensitivity, and relevant usage context

D. Removing the identity of the reviewer

Correct Answer: C. Providing business justification, resource sensitivity, and relevant usage context

Question 9

A service identity has read access to an entire production data lake although its pipeline uses one dataset. Which principle indicates the required correction?

A. Least privilege

B. Open federation

C. Shared accountability

D. Maximum retention

Correct Answer: A. Least privilege

Question 10

Which is a major risk of centralizing authentication in one identity provider?

A. It prevents any use of MFA.

B. A compromise may affect many dependent applications.

C. It makes identity records impossible to audit.

D. It eliminates the need for recovery procedures.

Correct Answer: B. A compromise may affect many dependent applications.