Every secure information system must answer four related questions: Who is requesting access? Is the claimed identity genuine? What is that identity allowed to do? What evidence should be recorded? These questions correspond to identification, authentication, authorization, and accounting (often called AAA). Together they form the foundation of network security.

Identity and access management (IAM) is the collection of policies, processes, technologies, and personnel used to manage digital identities and their access to resources. IAM applies to employees, contractors, customers, applications, devices, services, and automated agents. Poor IAM is a major cause of data breaches because attackers frequently exploit stolen credentials, excessive privileges, weak password controls, and poorly governed remote access.

This chapter explains the principles and practical implementation of IAM in organizational networks. It covers authentication factors, password controls, multifactor authentication (MFA), centralized authentication protocols, directory services, federation, role-based access control (RBAC), privileged access, remote access, and accounting.

Learning Objectives

1. The AAA Model

Identification

Identification is the act of claiming an identity. A username, email address, employee number, device identifier, or certificate subject may identify a principal. Identification alone provides no assurance that the claimant is genuine. For example, entering [email protected] states an identity but does not prove ownership of that account.

Authentication

Authentication is the process of verifying a claimed identity. The verifier compares presented evidence with trusted information. Authentication evidence is commonly classified into four factors:

Factor	Meaning	Examples
Knowledge	Something the subject knows	Password, PIN, recovery answer
Possession	Something the subject has	Hardware token, phone, smart card
Inherence	Something the subject is	Fingerprint, facial characteristic
Location or behavior	Where or how the subject acts	Network location, typing pattern

MFA requires evidence from at least two independent factor categories. Entering a password and a one-time code generated by a hardware token is MFA. Entering a password and another password is not, because both are knowledge factors.

Independence matters. If a phone receives both the password-reset link and the one-time code, compromise of that phone may defeat both controls. Similarly, a biometric unlock that merely releases a password stored on the same device may not provide the same assurance as two separately protected factors.

Authorization

Authorization determines what an authenticated subject may access or perform. It can be expressed as permissions over objects and operations. A user may be permitted to read a database but not modify it; a help-desk technician may reset passwords but not view payroll records.

Authorization decisions should consider the subject, resource, action, context, and policy. Context may include time, device health, network location, risk level, and transaction value. Authentication answers “Who are you?” Authorization answers “What may you do here?”

Accounting and Auditing

Accounting records security-relevant activity. Useful records include successful and failed logins, administrative changes, privilege elevation, access to sensitive files, token issuance, configuration changes, and session termination. Logs should contain a reliable timestamp, subject, source, action, target, result, and correlation identifier where possible.

Accounting supports incident investigation, compliance, billing, capacity planning, and non-repudiation. It does not automatically prove that a human personally performed an action: shared accounts, stolen credentials, compromised endpoints, and inaccurate clocks weaken attribution. Therefore, organizations should prohibit shared privileged accounts, synchronize clocks, protect logs from alteration, and review high-risk events.

2. Access-Control Models and Principles

Discretionary Access Control

In discretionary access control (DAC), the owner of a resource can generally decide who may access it. File permissions and access-control lists are common examples. DAC is flexible but can permit users to propagate access in ways that conflict with organizational policy.

Mandatory Access Control

Mandatory access control (MAC) applies centrally defined labels and rules. A subject with a security clearance may access an object only when the system policy permits the relationship between the subject’s clearance and the object’s classification. MAC is useful in military, government, and high-assurance environments, although it may be difficult to administer in rapidly changing organizations.

Role-Based Access Control

RBAC grants permissions to roles rather than directly to individual users. Users acquire roles according to job responsibilities. For example, the role “accounts-payable clerk” may include permissions to create invoices but not approve payments.

Static separation of duty prevents a user from holding conflicting roles. Dynamic separation of duty prevents conflicting actions within the same transaction or session. For example, one employee may prepare a payment while another must approve it.

RBAC is more manageable than individually assigning hundreds of permissions, but it can produce role explosion if every small variation becomes a new role. Periodic access reviews and carefully designed role boundaries are essential.

Attribute- and Risk-Based Decisions

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might state: “A clinician may view a patient record when assigned to the patient’s care team, using a managed device, during an active shift.” ABAC provides fine-grained context but requires reliable attributes and more complex policy administration.

Modern zero-trust architectures use continuous evaluation rather than assuming that an internal network is trustworthy. Access is granted to a specific resource for a specific purpose, and the decision may be reevaluated as context changes.

Least Privilege and Need to Know

Least privilege gives a subject only the permissions required for an authorized task, for only as long as needed. Need to know is a related information-sharing principle: a person may have a legitimate organizational role but still not require access to every item of information within that role.

Least privilege reduces the impact of compromised accounts and mistakes. It must apply to users, administrators, service accounts, applications, containers, and devices. It should be implemented through default-deny rules, scoped permissions, time-limited elevation, and regular reviews.

3. Passwords and Credential Controls

Passwords remain common, but their security depends on creation, storage, use, and recovery processes. A service should never store ordinary passwords in plaintext. Instead, it should store a password-derived verifier produced by a slow, modern password-hashing function with a unique salt. A salt prevents identical passwords from producing identical stored values and makes precomputed tables less useful. Password encryption is not a substitute for password hashing when the service does not need to recover the original password.

Password policy should encourage long, memorable passphrases and prevent known-compromised passwords. Arbitrary complexity rules can lead users to predictable patterns and frequent reuse. Controls should include:

Password strength is not determined by length alone. A long phrase copied from a public quotation may be predictable, while a randomly generated password has stronger resistance to guessing. Organizations should avoid forcing routine password changes without evidence of compromise; instead, they should require immediate rotation after suspected exposure and use risk-based controls.

Password databases must be protected with access controls, encryption for backups, monitoring, and a memory-hard password-hashing scheme appropriate to the platform. Account lockout requires care: an attacker can deliberately lock many accounts, creating denial of service. Progressive delays, risk-based challenges, and monitored throttling may be safer than permanent lockout.

4. Multifactor Authentication

MFA reduces the value of a stolen password but does not eliminate all risk. Common mechanisms include:

Phishing-resistant methods, such as security keys using WebAuthn/FIDO2, bind authentication to the legitimate site or service and are generally stronger than codes manually entered into a fraudulent site. Push-based MFA can be abused through repeated prompts, known as push fatigue. Organizations should use number matching, risk signals, user education, and prompt-rate limits.

MFA deployment must include enrollment, recovery, replacement, revocation, and support processes. A secure factor can be undermined by an insecure recovery process. Help-desk staff should verify identity using independent evidence and should never disable MFA merely because a caller requests it.

5. Centralized Network Authentication

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is widely used for network access, including wireless LANs, VPNs, and network access servers. A client, such as an access point, sends an authentication request to a RADIUS server. The server consults a user directory or identity store and returns an accept or reject decision, often with authorization attributes such as VLAN assignment or session limits. RADIUS also supports accounting messages for session start, interim updates, and stop events.

In traditional RADIUS deployments, the shared secret protects selected protocol exchanges between the client and server; it does not mean that every part of the communication is end-to-end encrypted. Deployments should use protected transport options where available, restrict clients by source address, use strong unique shared secrets, and monitor server certificates when TLS-based variants are used.

TACACS+

TACACS+ is commonly used to control administrative access to routers, switches, and firewalls. It separates authentication, authorization, and accounting more distinctly than traditional RADIUS and can authorize individual commands. This enables a policy such as allowing an operator to view configuration but requiring approval for destructive commands.

RADIUS is often selected for user and device network access, while TACACS+ is often selected for granular network-device administration. The choice depends on product support, architecture, transport protection, and operational requirements; neither protocol removes the need for sound identity governance.

6. Kerberos and Directory Services

Kerberos is a ticket-based authentication protocol designed for trusted network environments. It uses a trusted Key Distribution Center (KDC), logically divided into an Authentication Server (AS) and Ticket-Granting Server (TGS). A user first authenticates to the AS and receives a ticket-granting ticket (TGT). The client presents the TGT to the TGS to request a service ticket for a particular application. The client then presents the service ticket to the application server.

Kerberos avoids sending the user’s password to each service. It supports mutual authentication and time-limited tickets. Correct time synchronization is important because timestamps help prevent replay attacks. The KDC is highly sensitive: compromise can affect many services. Organizations should protect it, restrict administrative access, monitor ticket activity, and plan for service continuity.

Directory services provide centralized storage and lookup for identities, groups, devices, policies, and organizational information. LDAP is a directory access protocol, not itself a complete authentication architecture. Directory entries are organized hierarchically and may contain attributes such as names, group membership, public keys, and account status.

Secure directory deployments use encrypted connections, strong administrative controls, restricted searches, appropriate schema design, and lifecycle processes. Identity data is personal data in many contexts, so directory contents should be minimized and access logged.

7. Federation and Single Sign-On

Federation allows an identity provider (IdP) to authenticate a subject for a relying party or service provider (SP). The organization’s IdP may issue an assertion stating that a subject authenticated and possesses specified attributes. The service provider validates the assertion and creates a local session.

Single sign-on (SSO) lets a user authenticate once and access multiple approved services. SSO improves usability and can reduce password reuse, but it concentrates risk in the identity provider. Strong MFA, secure session management, short-lived tokens, careful trust configuration, and rapid revocation are therefore essential.

Common technologies include Security Assertion Markup Language (SAML), often used for browser-based enterprise federation, and OpenID Connect (OIDC), an identity layer built on OAuth 2.0. OAuth primarily addresses delegated authorization: an application receives limited access to a resource without receiving the user’s password. OIDC adds standardized authentication information and identity tokens.

Federation requires trust governance. Organizations must validate issuer identity, audience, signature, expiry, nonce or state protections, redirect URIs, scopes, and attribute release. Overly broad claims can disclose personal information or grant excessive access.

8. Privileged and Remote Access

Privileged accounts can change security controls, create accounts, alter systems, or access sensitive information. They deserve stronger controls than ordinary accounts:

Emergency or “break-glass” accounts should be few, tightly protected, monitored, and tested periodically. Their credentials should be stored securely and used only under documented emergency procedures.

Remote access should authenticate both the user and, where appropriate, the device. A VPN alone does not guarantee security: a stolen credential can still provide access through it. Secure remote-access design combines MFA, device posture checks, least-privilege application access, segmentation, endpoint protection, logging, and rapid revocation. Administrative access should use a controlled jump host or management network rather than exposing management interfaces directly to the Internet.

9. Identity Lifecycle and Governance

Identity security is a lifecycle rather than a one-time configuration. Joiner, mover, and leaver processes should connect human-resources events with account provisioning and deprovisioning. A new employee receives only approved baseline access; a transfer triggers review of old and new permissions; departure causes prompt disabling of accounts, sessions, tokens, keys, and remote access.

Governance should define ownership for identities, applications, roles, and data. Access certifications require managers or resource owners to confirm that permissions remain necessary. Automated provisioning reduces delay and error, but automation must be tested because an incorrect source record can propagate excessive access at scale.

Useful operational measures include the proportion of privileged accounts using MFA, time to disable departed-user accounts, number of orphaned accounts, age of access-review exceptions, and volume of authentication anomalies. Metrics should support decisions rather than reward superficial compliance.

10. Applied Case: Northbridge Community Hospital

Background

Northbridge Community Hospital operates clinical applications, laboratory systems, finance services, wireless networks, and a remote-support platform. It has 1,200 staff, visiting clinicians, contractors, and connected medical devices.

Problem

An audit found shared administrator accounts, inconsistent termination procedures, password-only VPN access, excessive access to patient records, and incomplete logs. A former contractor’s account remained active for several weeks after the contract ended.

Analysis

The hospital’s identity problem was systemic. Identification was not reliably linked to an individual because accounts were shared. Authentication relied on passwords vulnerable to phishing. Authorization was based mainly on broad groups rather than clinical duties. Accounting could not establish responsibility because logs recorded generic administrator names. The risks included privacy violations, ransomware propagation, unsafe clinical changes, and regulatory penalties.

Approach and Solution

Northbridge implemented a central directory integrated with HR records. Each worker received a unique account, while shared accounts were removed or converted into controlled service identities. RBAC roles were created for nurses, physicians, laboratory staff, finance personnel, help-desk staff, and infrastructure administrators. Access to patient records was further constrained by department, assignment, and treatment context.

The hospital deployed phishing-resistant MFA for administrators and VPN users, with a secure recovery process. Network devices used TACACS+ for command authorization and accounting. RADIUS supported wireless and VPN authentication, while a SIEM collected authentication and privilege events. Administrative access required a managed workstation and a jump host. Departures automatically disabled accounts and revoked sessions, tokens, and certificates.

Outcome

The hospital reduced standing administrator privileges, improved attribution, and shortened account-deactivation time. Security staff could investigate unusual access by linking a named identity, device, command, and time. Clinical leaders retained responsibility for approving access, while technical teams implemented the controls.

Learning Points

The case demonstrates that IAM is not simply a login technology. Effective protection combines identity proofing, strong authentication, carefully scoped authorization, lifecycle governance, monitoring, and accountable human ownership. Automation improves consistency, but policy and review remain necessary.

11. Challenges, Ethics, and Contemporary Developments

IAM systems create power over people’s access to work, healthcare, education, and public services. Biometric systems raise concerns about consent, proportionality, false matches, exclusion, and the fact that biometric traits cannot be changed easily after compromise. Organizations should provide lawful, accessible alternatives where appropriate and retain only necessary data.

Monitoring must balance security with privacy. Employees should be informed about what is logged, why it is collected, who can inspect it, and how long it is retained. Access decisions should be explainable enough to support appeals and error correction, especially when automated risk scoring is used.

Artificial intelligence can help detect impossible travel, unusual privilege use, password spraying, and abnormal access patterns. However, AI-generated risk scores can produce false positives, encode bias, or be manipulated by attackers. Human review, documented thresholds, protected training data, and a clear response process are essential. AI should assist—not silently replace—accountability for consequential access decisions.

Contemporary IAM is moving toward passwordless authentication, passkeys, continuous access evaluation, decentralized identity experiments, workload identity, and zero-trust architectures. These developments do not remove fundamental requirements: trustworthy identity proofing, secure key management, least privilege, resilient recovery, clear governance, and effective monitoring.

Best-Practice Checklist

Chapter Summary

Identity and access management provides the control structure through which organizations recognize subjects, verify claims, grant permissions, and record activity. The AAA model distinguishes identification, authentication, authorization, and accounting. Authentication assurance improves when independent factors are combined, especially through phishing-resistant MFA. Passwords require secure hashing, unique use, breach screening, rate limiting, and protected recovery.

DAC, MAC, RBAC, and ABAC provide different ways to express authorization. Least privilege, need to know, separation of duties, and default deny reduce the consequences of compromise. RADIUS commonly supports network access and accounting, while TACACS+ provides granular administration of network devices. Kerberos uses trusted, time-limited tickets, and directory services centralize identity information. Federation and SSO improve usability but make the identity provider a critical trust anchor.

Privileged and remote access require stronger authentication, device controls, session monitoring, time-limited elevation, and rapid revocation. Effective IAM also depends on lifecycle governance, privacy, ethical use of monitoring, reliable logging, and accountable human review. New technologies such as passkeys, zero trust, workload identity, and AI-assisted detection extend these principles rather than replacing them.

Key Terms

Multifactor authentication: Authentication using evidence from at least two independent factor categories.

Attribute-based access control: Making decisions using subject, resource, action, and environmental attributes.

Separation of duties: Dividing conflicting responsibilities among people or roles.

RADIUS: A protocol commonly used for centralized network access authentication and accounting.

TACACS+: A protocol commonly used for granular authentication, authorization, and accounting of network-device administration.

Kerberos: A ticket-based network authentication protocol using a trusted Key Distribution Center.

Directory service: A structured repository for identities, groups, devices, and related attributes.

Identity provider: A trusted service that authenticates subjects and issues identity assertions or tokens.

Federation: An arrangement allowing one identity domain to provide authentication to another service.

Single sign-on: Access to multiple approved services after one authentication event.

Privileged access management: Controls for protecting, granting, monitoring, and reviewing high-impact access.

Phishing-resistant authentication: Authentication designed to prevent credentials or authentication evidence being reused at an impostor site.

Zero trust: A security approach that continually evaluates access rather than trusting a network location by default.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which AAA function determines whether an authenticated user may read a particular file?

Question 2

Question 3

Correct Answer: B. To make identical passwords produce different stored values

Question 4

Which protocol is commonly associated with granular command authorization on network devices?

Question 5

In Kerberos, what does a client normally obtain from the Ticket-Granting Server?

Question 6

Question 7

What is a major security advantage of phishing-resistant authentication such as a security key?

Correct Answer: C. It helps prevent authentication evidence being reused at an impostor site

Question 8

Question 9

Correct Answer: B. Use separate accounts and time-limited elevation for administrative tasks

Chapter 8 Identity, Authentication and Access Control

Identity, Authentication and Access Control

Introduction and Context