Identity, Authentication and Access Control

Introduction and Context

Modern network security is increasingly identity-centric. Traditional perimeter controls assumed that users and systems inside an enterprise network were trustworthy. Cloud computing, remote work, mobile devices, software-defined infrastructure, APIs, and zero-trust architectures have weakened that assumption. Access decisions must now be based on verified identities, authenticated devices, contextual risk, and explicitly defined policy.

Identity and access management (IAM) provides the organizational and technical framework for answering four questions: Who is requesting access? How was that identity verified? What is the requester allowed to do? How can the organization prove that access was appropriate? These questions correspond closely to identification, authentication, authorization, and accountability—the central elements of the AAA model.

This chapter examines AAA, role-based and attribute-based access control, multifactor authentication, single sign-on, federation, Kerberos, RADIUS, TACACS+, OAuth, OpenID Connect, privileged access management, and machine identity governance. It also considers design trade-offs, operational risks, regulatory responsibilities, and a practical enterprise case.

Learning Objectives

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

1. Distinguish identification, authentication, authorization, accounting, and auditing.

2. Design access policies using RBAC, ABAC, least privilege, and separation of duties.

3. Explain the operation and limitations of MFA, SSO, federation, Kerberos, RADIUS, and TACACS+.

4. Differentiate OAuth from OpenID Connect and select suitable protocol patterns.

5. Design controls for privileged accounts and machine identities.

6. Evaluate IAM architectures from security, usability, operational, governance, and compliance perspectives.

Identity as a Security Control

An identity is a representation of a human, service, device, application, or organization. Digital identity is not merely a username; it includes identifiers, credentials, attributes, relationships, authentication history, and lifecycle status. A single individual may have separate identities in a university, cloud platform, and research system, or these identities may be linked through federation.

The identity lifecycle normally includes creation, provisioning, modification, suspension, and deletion. Failure at any stage creates risk. For example, an account that remains active after an employee leaves is an orphaned identity. An account with excessive permissions is an overprivileged identity. A shared administrator account prevents reliable attribution and weakens accountability.

Important identity principles include:

• Least privilege: grant only the permissions required for an approved task.
• Need to know: restrict information access to what a subject requires.
• Separation of duties: divide sensitive actions among multiple people or roles.
• Default deny: reject access unless policy explicitly permits it.
• Complete mediation: validate authorization whenever a protected resource is accessed, subject to carefully designed performance controls.
• Accountability: record actions so that they can be traced to an identified subject or workload.
• Lifecycle governance: review, modify, and revoke access as circumstances change.

The AAA Model

AAA commonly means authentication, authorization, and accounting. In some governance contexts, auditing is treated as a fourth related function.

Identification is the claim of an identity, such as entering a username or presenting a certificate subject. Identification alone does not prove the claim.

Authentication verifies a claimed identity using one or more authentication factors:

• Something the subject knows, such as a password or PIN.
• Something the subject possesses, such as a hardware token or private key.
• Something the subject is, such as a fingerprint or facial characteristic.
• Somewhere the subject is, such as a network location, although location is better understood as a contextual signal than a primary factor.
• Something the subject does, such as a behavioral pattern.

Authorization determines whether an authenticated subject may perform a requested action on a resource. Authorization should be evaluated against policy, not inferred merely from successful login.

Accounting records sessions, commands, resource use, and administrative events. Accounting supports billing, incident investigation, capacity planning, and non-repudiation-related controls. Logs alone do not guarantee non-repudiation; legal non-repudiation depends on the evidence model, cryptographic controls, governance, and applicable law.

Auditing evaluates whether identity and access controls operated as intended. It includes log review, access recertification, control testing, and investigation of anomalies.

A robust AAA transaction therefore has the following logical sequence: a subject presents an identity claim, the claim is authenticated, policy evaluates the requested action and context, access is granted or denied, and the event is recorded.

Authentication Assurance and Multifactor Authentication

Authentication strength depends on the independence and resistance to compromise of the factors used. Two passwords are generally not multifactor authentication because both are knowledge factors. A password combined with a phishing-resistant security key is materially stronger.

MFA implementations include one-time passwords, push notifications, smart cards, client certificates, and public-key authenticators. However, MFA is not automatically secure. SMS codes can be exposed through SIM swapping or telecommunications interception. Push authentication may be abused through repeated approval requests, known as push fatigue. TOTP codes are vulnerable to phishing if users enter them into a fraudulent site. FIDO2/WebAuthn-style authenticators provide stronger phishing resistance because the credential is bound to the legitimate relying-party origin.

Good MFA design includes risk-based step-up authentication, recovery procedures, device registration controls, protection against enrollment fraud, and secure handling of backup factors. Biometric data deserves special care: unlike a password, a compromised biometric characteristic cannot simply be replaced. Biometrics are therefore commonly used to unlock a device-held credential rather than serve as a remotely transmitted secret.

Authentication assurance should be proportional to risk. A public information page may require no login; payroll administration, cryptographic key management, and production infrastructure require strong authentication, careful device posture evaluation, and privileged-session monitoring.

Authorization Models

Role-Based Access Control

RBAC assigns permissions to roles and assigns users or service identities to roles. A permission is an approved operation on a resource, such as read-report or modify-firewall-rule. Roles simplify administration because access is managed through job functions rather than individually assigned permissions.

A basic RBAC structure consists of users, roles, permissions, sessions, and constraints. A user may activate only selected roles in a session. Constraints can enforce separation of duties, such as preventing one person from both requesting and approving a payment.

RBAC is effective when organizational responsibilities are relatively stable. Its limitations include role explosion, difficulty representing contextual conditions, and the risk that accumulated role membership creates excessive privilege. Periodic role review and carefully designed role engineering are essential.

Attribute-Based Access Control

ABAC evaluates attributes of the subject, object, action, and environment. A policy might state: “Permit a clinician to view a patient record when the clinician is assigned to that patient, the purpose is treatment, the device is managed, and the session has strong authentication.”

ABAC is expressive and suitable for dynamic, distributed environments. Subject attributes may include department, clearance, employment status, or assurance level. Object attributes may include classification, owner, and data type. Environmental attributes may include time, location, device health, threat level, and transaction risk.

The flexibility of ABAC creates governance challenges. Attributes must be accurate, authoritative, current, and protected from unauthorized modification. Policies should be explainable, testable, version-controlled, and evaluated for conflicts. Poorly governed ABAC can become opaque and difficult to audit.

Hybrid and Policy-Based Control

Many enterprises combine RBAC and ABAC. A role establishes broad eligibility, while attributes and context refine the decision. For example, a database administrator role may permit database maintenance, but access may still require a managed device, a ticket reference, an approved time window, and step-up authentication.

Policy decision points evaluate requests; policy enforcement points intercept and enforce decisions; policy administration points create and manage policies; and policy information points supply trusted attributes. This conceptual separation is useful in zero-trust architectures, API gateways, service meshes, and cloud authorization systems.

SSO and Federation

Single sign-on allows a user to authenticate once to an identity provider and access multiple relying applications without separately entering credentials into each application. SSO improves usability and can reduce password reuse, but it concentrates risk: compromise of the identity provider or session can affect many applications. Strong authentication, session protection, rapid revocation, and careful application integration are therefore required.

Federation establishes trust between administrative domains. An identity provider authenticates a subject and conveys an assertion or token to a service provider. Federation avoids duplicating passwords across organizations and supports academic, commercial, and partner access.

SAML is a widely used XML-based federation framework, especially for browser-based enterprise SSO. OpenID Connect (OIDC) provides an identity layer on top of OAuth 2.0 and commonly uses JSON Web Tokens. Federation requires attention to issuer validation, audience restrictions, signature verification, token lifetime, clock synchronization, redirect URI controls, and account-linking logic. Trust is not created merely by accepting a token; the recipient must validate its meaning and provenance.

Kerberos

Kerberos is a ticket-based network authentication protocol based on symmetric cryptography and a trusted Key Distribution Center (KDC). The KDC commonly includes an Authentication Server and a Ticket-Granting Server.

A simplified exchange is:

1. A client authenticates to the Authentication Server and receives a Ticket-Granting Ticket (TGT).

2. The client presents the TGT to the Ticket-Granting Server to request a service ticket.

3. The client presents the service ticket to the target service.

4. The service validates the ticket and may mutually authenticate the client.

Kerberos avoids transmitting the user’s password to every service. It relies on secure KDC operation, synchronized clocks, protected service keys, appropriate ticket lifetimes, and correct principal management. KDC compromise is highly consequential. Kerberos is central to many domain-based enterprise environments, but it is less naturally suited to loosely coupled internet applications than modern federation protocols.

RADIUS and TACACS+

RADIUS is widely used for centralized authentication, authorization, and accounting in network access scenarios such as wireless access, VPNs, and network access servers. A network access server acts as a client to the RADIUS server. RADIUS commonly uses UDP and historically protected only selected credential material in transit; deployments should use modern protected transport options where supported and secure the entire communication path.

TACACS+ is commonly used for administrative access to network devices. It separates authentication, authorization, and accounting more distinctly than traditional RADIUS deployments and supports granular command authorization. TACACS+ is therefore often preferred for device administration, while RADIUS is frequently used for user or device network access. The choice depends on vendor support, architecture, transport protection, and operational requirements rather than on a simplistic claim that one protocol is universally superior.

Both protocols require resilient servers, shared-secret protection, timeouts, failover planning, logging, and explicit treatment of emergency access when the central service is unavailable.

OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework that enables a client to obtain limited access to a resource server on behalf of a resource owner. OAuth answers “What may this client access?” It does not, by itself, provide a standardized user-authentication protocol.

The principal entities are the resource owner, client, authorization server, and resource server. In the authorization-code flow, the client redirects the user to the authorization server, receives an authorization code, and exchanges that code for an access token. The use of PKCE protects public clients against interception of the authorization code. Redirect URIs must be exact and controlled; access tokens should have limited scope and lifetime.

OpenID Connect adds authentication to OAuth 2.0. It introduces an ID token containing claims about the authentication event and the subject. A client must validate the token issuer, audience, signature, expiration, nonce, and relevant authentication context. An ID token is intended for the client and should not be used as a general API access token.

Common implementation failures include treating an access token as proof of identity, accepting tokens from an unintended issuer, using overly broad scopes, storing tokens insecurely, and permitting open redirectors. Secure design begins with a clear separation between authentication, authorization, token issuance, and resource-server validation.

Privileged Access Management

Privileged accounts can alter security controls, extract sensitive data, create identities, or disable monitoring. Privileged access management (PAM) reduces this risk through controls such as:

• Separate administrative identities.
• Just-in-time and just-enough access.
• Approval workflows linked to business tickets.
• Credential vaulting and automated rotation.
• Session recording and command auditing.
• Time-limited elevation.
• Strong MFA and managed administrative workstations.
• Emergency or break-glass accounts with strict monitoring.

PAM is not simply a password vault. It is a governance and operational discipline that reduces standing privilege and improves attribution. Emergency accounts should be tested periodically, protected from routine use, and reviewed after every activation. Session recording must be balanced with privacy, legal requirements, storage protection, and clear retention rules.

Machine Identity Governance

Non-human identities include service accounts, workload identities, API keys, certificates, signing keys, cloud roles, IoT credentials, and software agents. They frequently outnumber human accounts and may have long lifetimes, unclear owners, and excessive privileges.

A machine identity program should maintain an inventory containing the owner, purpose, environment, issuer, permissions, creation date, expiration date, dependencies, and rotation method. Prefer short-lived, automatically issued credentials and workload identity federation over embedded static secrets. Secrets should not be stored in source code, container images, or unprotected configuration files.

Certificate governance includes secure key generation, certificate enrollment, renewal, revocation, trust-store management, and monitoring for expiration. Rotation must be tested because poorly implemented rotation can interrupt production services. Machine identities should be included in access reviews, incident response, software supply-chain controls, and decommissioning procedures.

Identity Governance, Risk, and Compliance

Identity governance connects technical controls to organizational authority. Joiner-mover-leaver processes should be integrated with authoritative human-resources or student-information systems. Access requests should identify a business owner, justification, duration, and approving authority. Periodic access recertification should focus on meaningful risk rather than becoming an automatic approval exercise.

Important evidence includes authentication events, authorization decisions, administrative actions, provisioning records, access reviews, and exception approvals. Logs should be time-synchronized, protected against unauthorized alteration, monitored for suspicious patterns, and retained according to legal and business requirements.

Privacy must be considered in identity analytics. Collect only necessary attributes, limit access to identity data, define retention periods, and explain monitoring practices. Automated risk scoring and AI-assisted anomaly detection may prioritize investigations, but they can produce false positives, encode bias, or create opaque decisions. Human review, model validation, appeal mechanisms, and data-protection controls are essential where automated decisions affect individuals.

Illustrative Case: Federated Access for a Research University

Background: A research university operates laboratories, cloud platforms, campus Wi-Fi, a high-performance computing cluster, and partner projects. Researchers, students, contractors, and visiting scholars use different accounts. Several former contractors retain active credentials, and laboratory administrators share privileged accounts.

Problem: The university needs convenient access across institutions while protecting regulated research data and preventing unauthorized changes to laboratory infrastructure.

Analysis: A single local directory cannot safely represent all external affiliations. Shared administrator accounts undermine accountability. Static service credentials embedded in scripts create machine-identity risk. The university also needs stronger authentication for sensitive data than for ordinary student services.

Approach: The university establishes a central identity provider and federates partner access using OIDC and SAML according to application capability. Home institutions authenticate their own users, while the university maps trusted claims into local roles. ABAC policies require research affiliation, project membership, managed devices, and appropriate authentication assurance before granting access to regulated datasets. RBAC remains the basis for laboratory and cluster roles. Privileged administrators use separate identities, phishing-resistant MFA, just-in-time elevation, and recorded sessions. Network access uses RADIUS, while device administration uses TACACS+ with command authorization. Workloads receive short-lived identities from an automated issuer rather than shared passwords.

Outcome: User onboarding becomes faster, former affiliations can be revoked through authoritative lifecycle events, and administrative actions are attributable. The university still must monitor federation trust, validate claims, review mappings, test emergency access, and maintain recovery procedures if the identity provider is unavailable.

Learning points: Federation reduces account duplication but does not remove local responsibility. Hybrid RBAC and ABAC can combine stable job functions with contextual controls. PAM and machine identity governance are necessary complements to human authentication.

Design Challenges and Best Practices

IAM programs often fail through excessive complexity, incomplete inventories, weak ownership, and poor exception management. Common challenges include legacy applications that cannot support MFA, inconsistent identity attributes, directory synchronization errors, account recovery fraud, token leakage, and availability dependence on central identity services.

Recommended practices include:

1. Classify applications and data by risk before selecting authentication assurance.

2. Establish authoritative sources for identity attributes and lifecycle events.

3. Prefer phishing-resistant MFA for high-risk access.

4. Use RBAC where responsibilities are stable and ABAC where context is essential; govern both with policy review and testing.

5. Separate authentication from authorization and validate tokens at every appropriate trust boundary.

6. Eliminate shared privileged accounts and reduce standing privilege.

7. Inventory and rotate machine credentials, certificates, and API keys.

8. Design high availability, backup, and break-glass procedures for identity services.

9. Monitor anomalous authentication, impossible travel, unusual privilege elevation, and mass token use, while investigating alerts with human oversight.

10. Measure outcomes such as orphaned-account closure time, MFA coverage, privileged-session review completion, credential rotation compliance, and access-review quality.

Chapter Summary

Identity-centric security treats users, devices, applications, and workloads as governed subjects whose access must be authenticated, authorized, monitored, and revoked throughout the lifecycle. AAA provides the foundational structure: authentication establishes identity, authorization evaluates permitted actions, and accounting supports accountability. RBAC offers manageable job-function permissions, while ABAC adds attributes and context for dynamic decisions. MFA strengthens authentication, especially when phishing-resistant factors are used.

SSO and federation improve usability and support cross-domain access but concentrate trust and require rigorous token and trust validation. Kerberos provides ticket-based enterprise authentication; RADIUS is widely used for network access; TACACS+ is valuable for administrative device control. OAuth 2.0 is an authorization framework, whereas OpenID Connect adds standardized authentication. PAM limits the danger of privileged accounts, and machine identity governance addresses the growing population of service accounts, certificates, keys, and workload identities. Effective IAM combines technology with lifecycle governance, privacy protection, auditing, resilience, and accountable policy ownership.

Key Terms

Identity: A digital representation of a human, device, application, or organization.

Authentication: Verification of a claimed identity.

Authorization: Determination of permitted actions on resources.

Accounting: Recording of access, usage, and administrative events.

AAA: Authentication, authorization, and accounting.

MFA: Authentication using two or more independent factor types.

RBAC: Access control based on organizational roles.

ABAC: Access control based on subject, object, action, and environmental attributes.

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

Separation of duties: Dividing sensitive responsibilities among multiple actors.

SSO: Single sign-on across multiple applications.

Federation: Trust-based exchange of identity assertions between domains.

Kerberos: Ticket-based authentication protocol using a trusted KDC.

RADIUS: AAA protocol commonly used for network access.

TACACS+: AAA protocol commonly used for network-device administration.

OAuth 2.0: Framework for delegated authorization.

OpenID Connect: Authentication and identity layer built on OAuth 2.0.

PAM: Controls for governing and monitoring privileged access.

Machine identity: Identity representing a non-human workload, service, device, or application.

Policy enforcement point: Component that enforces an access-control decision.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accounting.

2. Why are two passwords not normally considered multifactor authentication?

3. State one major strength and one limitation of RBAC.

4. What additional capability does OpenID Connect provide beyond OAuth 2.0?

5. Why should machine identities have owners and expiration or rotation controls?

Long Answer Questions

1. Explain how a hybrid RBAC and ABAC architecture can support a zero-trust enterprise.

2. Describe the Kerberos ticket exchange and discuss its principal security assumptions.

3. Compare RADIUS and TACACS+ in terms of typical use, authorization granularity, and operational concerns.

4. Explain the security benefits and risks of SSO and federation.

5. Design a privileged access management program for a medium-sized cloud infrastructure team.

Analytical / Application Questions

1. A contractor changes projects but retains access to the former project’s database. Analyze the lifecycle and governance failures and propose corrective controls.

2. An organization uses OAuth access tokens as evidence of user identity in its web application. Evaluate the design and recommend an OIDC-based correction.

3. A university wants passwordless access for researchers, visiting scholars, laboratory administrators, and automated workloads. Develop a differentiated identity architecture that addresses MFA, federation, PAM, and machine identity governance.

Multiple Choice Questions with Answers

Question 1

Which AAA function determines whether an authenticated user may execute a requested operation?

A. Identification

B. Authentication

C. Authorization

D. Accounting

Correct Answer: C. Authorization

Question 2

Which authentication method is generally most resistant to ordinary phishing attacks?

A. SMS one-time password

B. FIDO2/WebAuthn security key

C. Password plus security question

D. Email verification code

Correct Answer: B. FIDO2/WebAuthn security key

Question 3

Which statement best describes ABAC?

A. It assigns every permission directly to a user

B. It evaluates attributes of the subject, resource, action, and environment

C. It permits access only through Kerberos tickets

D. It replaces authorization with accounting

Correct Answer: B. It evaluates attributes of the subject, resource, action, and environment

Question 4

What is the primary purpose of a Kerberos service ticket?

A. To store a user’s password on every server

B. To authorize and authenticate access to a particular service

C. To replace all network encryption

D. To provide a public web redirect

Correct Answer: B. To authorize and authenticate access to a particular service

Question 5

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

A. TACACS+

B. DNS

C. SMTP

D. SAML

Correct Answer: A. TACACS+

Question 6

What is OAuth 2.0 primarily designed to provide?

A. Delegated authorization

B. Biometric enrollment

C. Hardware-based authentication only

D. File-system encryption

Correct Answer: A. Delegated authorization

Question 7

What does OpenID Connect add to OAuth 2.0?

A. A standardized identity and authentication layer

B. A replacement for all authorization policies

C. A network routing protocol

D. A password vaulting algorithm

Correct Answer: A. A standardized identity and authentication layer

Question 8

Which control most directly reduces standing administrator privilege?

A. Permanent membership in every administrator group

B. Just-in-time, time-limited elevation

C. Shared administrator passwords

D. Disabling administrative logging

Correct Answer: B. Just-in-time, time-limited elevation

Question 9

Which is a sound machine-identity practice?

A. Embedding permanent API keys in source code

B. Using short-lived credentials with automated issuance and rotation

C. Using one shared service account for all applications

D. Excluding service accounts from access reviews

Correct Answer: B. Using short-lived credentials with automated issuance and rotation

Question 10

In a policy-based access architecture, which component intercepts a request and enforces the policy decision?

A. Policy enforcement point

B. Policy information point

C. Human-resources system

D. Certificate authority only

Correct Answer: A. Policy enforcement point