Identity and Access Security

Introduction

Identity and access security concerns the controls used to establish who or what is requesting access, determine what that subject is permitted to do, and record whether the access was appropriate. It is a central part of network and Internet security because a technically secure network can still be compromised when an attacker obtains a legitimate account, when excessive permissions are assigned, or when authentication systems are poorly designed.

An identity is a representation of a person, device, service, or application within a system. Authentication establishes confidence in that identity. Authorization determines the actions the authenticated subject may perform. Accounting, auditing, and monitoring record what occurred. These functions are often summarized as the identity and access management (IAM) lifecycle: create, use, review, modify, suspend, and remove identities and their permissions.

This chapter presents foundational controls for secure passwords, multifactor authentication (MFA), role-based access control (RBAC), privileged access, directory services, federation, single sign-on (SSO), and common authentication protocols.

Learning Objectives

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

• distinguish identification, authentication, authorization, and accounting;
• implement practical password and credential protections;
• explain MFA and evaluate its strengths and weaknesses;
• apply least privilege, separation of duties, and RBAC;
• describe directory services, federation, and SSO;
• recognize the purposes of LDAP, Kerberos, SAML, OAuth 2.0, and OpenID Connect;
• identify risks associated with privileged accounts and service identities; and
• design foundational identity controls for a small organization.

The Identity and Access Control Process

A useful access decision can be represented as:

1. Identification: the subject claims an identity, such as a username or device identity.
2. Authentication: the system verifies evidence supporting the claim.
3. Authorization: policy determines whether the subject may perform the requested action on the resource.
4. Accounting and audit: the system records the event, including subject, resource, action, time, and result.

These stages are related but not interchangeable. A username identifies a claimed account; it does not prove ownership. Authentication does not automatically grant access to every resource. A successful login may be followed by an authorization denial.

A simple access-control model contains four elements:

Policies should be explicit, reviewable, and enforceable. They should also produce logs suitable for investigation. Access decisions based only on informal assumptions are difficult to audit and frequently create privilege accumulation.

Authentication Factors and Credentials

Authentication factors are commonly grouped into three categories:

• Knowledge: something the user knows, such as a password or PIN.
• Possession: something the user has, such as a hardware security key or registered phone.
• Inherence: something the user is, such as a fingerprint or face characteristic.

Location, device health, and behavioral patterns are useful contextual signals, but they are not normally treated as independent primary factors in the same sense as knowledge, possession, and inherence. MFA requires two or more factors from different categories. Entering a password and answering a second security question usually uses two knowledge elements, not true MFA.

Authentication factors differ in resistance to theft and impersonation. Passwords can be phished or reused. SMS codes can be intercepted through number-porting attacks or weaknesses in telecommunications systems. Authenticator applications reduce dependence on the mobile network but can still be defeated by real-time phishing. Hardware security keys using phishing-resistant standards provide stronger protection because the key binds authentication to the legitimate website origin.

Password Security

Passwords remain common, but their security depends on design and operational practice. Important controls include:

• require sufficiently long passwords or passphrases;
• block known compromised, common, and context-specific passwords;
• permit password managers and paste functions;
• avoid arbitrary frequent expiration when there is no evidence of compromise;
• rate-limit failed attempts and detect password-spraying patterns;
• protect password-reset processes as carefully as login processes; and
• never store passwords in plaintext.

A password verifier should store a salted, slow, memory-hard password hash rather than the password itself. A salt is a unique random value stored with the verifier. It prevents identical passwords from producing identical stored values and makes large precomputed tables less useful. Suitable password hashing technologies include Argon2id, scrypt, and bcrypt, selected and configured according to current security guidance and system capacity. General-purpose hashes such as raw SHA-256 are not appropriate password-storage mechanisms because they are designed to be fast.

A simplified representation is:

Here, V is the stored verifier, P is the password, S is a unique random salt, C represents the cost parameters, and H is the approved password-hashing function. The verifier is suitable only when the same algorithm and parameters are used during verification. The formula is conceptual; real implementations also store the algorithm identifier and parameters so that the system can migrate to stronger settings.

Password strength is affected by both length and predictability. A random password selected uniformly from an alphabet of size A and containing L characters has an idealized search space of A^L possibilities. Its theoretical entropy is:

E is measured in bits, L is the number of characters, and A is the number of possible characters at each position. This estimate assumes independent, uniformly random selection, an assumption that ordinary human-created passwords do not satisfy. Consequently, a long but predictable phrase may be weaker than a shorter randomly generated password.

Multifactor Authentication

MFA reduces the consequences of password theft by requiring additional evidence. A common sequence is:

Figure: A simplified multifactor authentication flow.

MFA is not automatically phishing-resistant. Push notifications may be abused through repeated approval requests, known as push fatigue. Organizations should use number matching, clear sign-in context, risk-based prompts, and phishing-resistant authenticators where practical. Recovery procedures require special attention: an attacker who can persuade support staff to replace a factor may bypass MFA entirely.

Authorization Models

Least Privilege and Separation of Duties

Least privilege grants only the access necessary for a subject to perform an approved task, for only as long as needed. It limits the damage caused by stolen credentials, malware, and mistakes. Separation of duties divides sensitive processes among people or roles so that one person cannot complete an entire fraudulent or dangerous transaction alone. For example, one employee may create a supplier and another may approve payment.

Access should be reviewed after job changes, periodically for sensitive systems, and immediately when employment or contracts end. Dormant accounts, shared accounts, and inherited group memberships are common sources of excessive access.

Role-Based Access Control

RBAC assigns permissions to roles and assigns users to roles. A user receives permissions indirectly through membership in one or more roles. For example, a “help-desk analyst” role may reset ordinary user passwords but may not administer domain controllers.

RBAC reduces administrative complexity and improves consistency, but poorly designed roles can become overly broad. Role engineering should begin with business tasks, resources, and approval responsibilities rather than with technical groups alone. Temporary or exceptional access should have an owner, an expiry time, and an audit trail.

Attribute-based access control (ABAC) evaluates attributes such as department, device state, data classification, location, and time. In practice, RBAC and ABAC can be combined: a role establishes baseline permission while contextual conditions restrict when and from where it may be used.

Privileged Access

Privileged accounts can alter security controls, create identities, access sensitive data, or affect many systems. Examples include domain administrators, cloud administrators, database administrators, root accounts, and emergency “break-glass” accounts.

Foundational privileged-access controls include:

• separate administrative and ordinary user accounts;
• MFA for every privileged account;
• just-in-time or time-limited elevation;
• approval for high-risk actions;
• privileged access workstations or hardened administration devices;
• session logging and command auditing where lawful and proportionate;
• removal of standing privileges where feasible;
• secure storage and rotation of service credentials; and
• tested emergency accounts protected by independent controls.

A common mistake is to protect an administrator’s interactive login while leaving an unattended service account with permanent, excessive privileges. Service identities should have narrowly scoped permissions, documented ownership, rotated credentials, and monitoring for unusual behavior. Secrets should be stored in an approved secrets-management system rather than in source code or scripts.

Directory Services

A directory is a structured store of identities, groups, devices, and attributes. Directory services provide a common source for authentication and authorization across systems. They support centralized administration, group membership, policy application, and account lifecycle processes.

LDAP is a protocol commonly used to query and modify directory information. It organizes entries in a hierarchical naming structure and can represent users, groups, organizational units, and devices. LDAP itself is not a complete identity architecture: deployments must protect communications using appropriate encryption, restrict anonymous queries, validate certificates, and apply access controls to directory operations.

Enterprise directory environments often synchronize identity data across multiple systems. Synchronization creates operational risk: a disabled account may remain active in a connected application if provisioning fails. Organizations therefore need reconciliation reports, failure alerts, ownership, and periodic comparison between authoritative sources and downstream systems.

Federation and Single Sign-On

Federation allows one organization or identity provider to provide authentication information to another service provider based on an agreed trust relationship. The identity provider authenticates the user; the service provider relies on a signed assertion or token and applies its own authorization rules.

SSO allows a user to authenticate once and access multiple related applications without entering credentials separately for each application. It improves usability and can reduce password reuse, but it also concentrates risk. Compromise of the identity provider, federation configuration, or user session can affect many applications.

Federated designs require careful control of:

• issuer and audience validation;
• signature verification and key rotation;
• token lifetime and replay prevention;
• redirect and logout behavior;
• attribute release and data minimization;
• clock synchronization; and
• emergency access when the identity provider is unavailable.

SSO is not the same as authorization. It answers, “Who authenticated?” The application must still decide what that identity may do.

Authentication Protocols

Kerberos

Kerberos is a ticket-based network authentication protocol. A trusted Key Distribution Center (KDC) commonly contains an Authentication Server and a Ticket-Granting Server. A client first obtains a ticket-granting ticket and then requests service tickets for particular services. The client presents a service ticket rather than sending the password to each service.

Kerberos depends on secure keys, correct service names, protection of the KDC, and reasonably synchronized clocks. Ticket theft, weak service-account keys, unconstrained delegation, and compromised endpoints remain important risks. Kerberos is widely associated with enterprise directory environments.

SAML

Security Assertion Markup Language (SAML) is commonly used for browser-based federation. An identity provider issues a signed assertion containing statements about authentication and attributes. A service provider validates the assertion before establishing a session. Secure implementation requires strict validation of issuer, audience, recipient, time conditions, signature, and response context.

OAuth 2.0

OAuth 2.0 is an authorization framework for delegated access. It allows a resource owner to authorize a client to obtain a limited access token for a resource server. OAuth access tokens are not, by themselves, proof of the end user’s identity. Modern deployments should use appropriate flows, protect redirect URIs, use state and nonce protections where applicable, and use Proof Key for Code Exchange (PKCE) for public clients.

OpenID Connect

OpenID Connect (OIDC) adds an identity layer to OAuth 2.0. It uses an ID token, normally a signed JSON Web Token, to convey authentication claims to a client. The client must validate the issuer, audience, signature, time claims, and nonce, and must distinguish the ID token from an access token. OIDC is widely used for modern web and mobile SSO.

Applied Case: Northbridge Training Services

Background

Northbridge Training Services, an illustrative small organization, uses cloud email, a learning platform, payroll software, and a local file server. Staff members have accumulated direct permissions, several former employees still have accounts, and administrators use the same account for email and system administration.

Problem and Analysis

A phishing incident captures an employee password. Investigation shows that password reuse allowed access to the learning platform, while a help-desk group granted unnecessary access to learner records. The organization has no reliable joiner–mover–leaver process and cannot determine which administrator changed a payroll permission.

The principal weaknesses are single-factor authentication, excessive authorization, weak lifecycle controls, shared administrative identities, and incomplete audit logging. The incident is not solved merely by changing one password because the underlying control environment remains unsafe.

Approach and Solution

Northbridge establishes an authoritative personnel record and assigns an owner for each application. It implements the following sequence:

1. require unique, long passphrases and block known compromised passwords;
2. deploy MFA, prioritizing phishing-resistant security keys for administrators;
3. create separate standard and administrative accounts;
4. design RBAC roles from actual job tasks and remove direct user permissions;
5. use SSO through an identity provider, with applications receiving only necessary attributes;
6. automate provisioning and deprovisioning, with alerts for failures;
7. place privileged elevation behind approval and time limits;
8. protect service credentials in a secrets manager;
9. centralize authentication and authorization logs; and
10. review sensitive access quarterly and after every role change.

Outcome and Learning Points

The organization reduces password exposure, improves visibility, and makes access removal more reliable. SSO simplifies the user experience, while MFA and least privilege reduce the impact of credential theft. The case also demonstrates that identity security is a governance process, not merely a login configuration. Ownership, review, evidence, and recovery procedures are essential.

Governance, Ethics, and Limitations

Identity systems process personal information, including usernames, device details, authentication events, and sometimes biometric data. Organizations should collect only necessary data, restrict access to logs, define retention periods, and comply with applicable privacy and employment laws. Biometric authentication deserves particular care because biometric traits cannot be replaced easily if compromised. Alternatives should be available where appropriate, and accessibility must be considered.

Security controls can create exclusion. Strict lockouts may deny legitimate users, risk-based systems may falsely classify people, and poorly designed MFA may disadvantage users with disabilities or limited connectivity. Controls should therefore be evaluated for usability, accessibility, proportionality, and recovery—not only theoretical strength.

No authentication method eliminates risk. Phishing, malware, insider misuse, compromised endpoints, federation errors, token theft, social engineering, and supply-chain failures can bypass otherwise strong controls. Defense in depth requires secure endpoints, network segmentation, application authorization, monitoring, incident response, and tested recovery.

Contemporary Developments and Best Practices

Modern identity programs increasingly adopt zero-trust principles: access is continuously evaluated rather than assumed from network location. Important signals include user identity, device posture, resource sensitivity, requested action, and current risk. Continuous evaluation must not become opaque surveillance; organizations need documented purposes, access controls, and human review for consequential decisions.

Passkeys and FIDO2-based authentication use public-key cryptography and can provide strong resistance to phishing. The private key remains protected by the authenticator, while the service stores a public key. Deployment still requires secure enrollment, account recovery, device replacement, and support for users who lose access.

A practical implementation checklist is:

• maintain an inventory of human, service, device, and application identities;
• define authoritative ownership and lifecycle events;
• require MFA according to risk, with phishing-resistant methods for privileged access;
• store passwords using approved salted, adaptive password hashing;
• apply least privilege, RBAC, separation of duties, and time-limited elevation;
• validate federation tokens and protect signing keys;
• monitor authentication failures, anomalous access, privilege changes, and dormant accounts;
• test deprovisioning, break-glass access, backups, and identity-provider outages; and
• review controls against current organizational policy and recognized security guidance.

Chapter Summary

Identity and access security protects systems by controlling who may access which resources, under what conditions, and with what accountability. Identification claims an identity; authentication verifies it; authorization applies policy; and accounting records the event. Secure password practice requires long, preferably unique credentials, compromised-password screening, rate limiting, and salted adaptive hashing. MFA strengthens authentication, especially when phishing-resistant possession factors are used.

Least privilege, separation of duties, RBAC, and contextual controls limit unauthorized activity. Privileged accounts require stronger safeguards, separate administration identities, time-limited elevation, monitoring, and secure service credentials. Directory services centralize identity data, while federation and SSO improve consistency and usability but concentrate risk. LDAP, Kerberos, SAML, OAuth 2.0, and OIDC serve different purposes and must not be treated as interchangeable. Effective IAM combines technology with lifecycle governance, privacy, accessibility, monitoring, and tested recovery.

Key Terms

Authentication: Verification of evidence supporting an identity claim.

Authorization: Determination of permitted actions on resources.

Accounting: Recording and reviewing access activity.

Multifactor authentication: Authentication using factors from at least two distinct categories.

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

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

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

Role-based access control: Assigning permissions to roles and users to roles.

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

Privileged account: Account capable of performing high-impact administrative actions.

Service account: Identity used by an application, process, or service.

Directory service: Structured identity store supporting lookup, administration, and policy.

LDAP: Protocol for accessing and managing directory information.

Federation: Trust relationship allowing one identity provider to support another service.

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

Kerberos: Ticket-based network authentication protocol.

SAML: XML-based federation standard commonly used for browser SSO.

OAuth 2.0: Framework for delegated authorization.

OpenID Connect: Identity layer built on OAuth 2.0.

Phishing-resistant authentication: Authentication designed to prevent credentials or assertions being redirected to an impostor site.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accounting.
2. Why should passwords be stored using salted adaptive hashing rather than plaintext or a fast general-purpose hash?
3. What makes MFA different from using two passwords?
4. State two benefits and one limitation of RBAC.
5. Why must an OAuth 2.0 access token not automatically be treated as proof of user identity?

Long Answer Questions

1. Explain how an organization should design a password and MFA policy for ordinary and privileged users.
2. Describe the identity lifecycle from account creation through deprovisioning, including audit requirements.
3. Compare directory services, federation, and SSO, and explain how they can be combined.
4. Explain the main risks of privileged and service accounts and propose practical controls.
5. Compare Kerberos, SAML, OAuth 2.0, and OIDC by purpose, trust model, and typical use.

Analytical / Application Questions

1. A former employee’s account remains active in three cloud applications after the central directory account was disabled. Analyze the likely lifecycle weaknesses and design a corrective process.
2. A company wants to replace passwords with SMS codes for all administrators. Evaluate this proposal and recommend a stronger authentication design.
3. Design an RBAC and privileged-access approach for a small college containing students, lecturers, finance staff, help-desk analysts, and system administrators. Explain how least privilege and separation of duties would operate.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do, while authorization verifies identity.

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

C. Authentication records events, while authorization encrypts passwords.

D. Authentication creates roles, while authorization synchronizes directories.

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

Question 2

Which option represents true multifactor authentication?

A. Password and security-question answer

B. Two different passwords

C. Password and hardware security key

D. Username and password

Correct Answer: C. Password and hardware security key

Question 3

Why is a unique salt used in password storage?

A. It allows plaintext recovery by administrators.

B. It makes identical passwords produce identical hashes.

C. It helps prevent precomputed-table attacks and reveals less about reused passwords.

D. It replaces the need for a password-hashing function.

Correct Answer: C. It helps prevent precomputed-table attacks and reveals less about reused passwords.

Question 4

What is the central principle of least privilege?

A. Every user receives administrator access temporarily.

B. Users receive only the access necessary for approved tasks.

C. All users receive identical permissions for consistency.

D. Permissions are never reviewed after assignment.

Correct Answer: B. Users receive only the access necessary for approved tasks.

Question 5

What is a principal risk of a permanently enabled domain administrator account?

A. It prevents all directory queries.

B. It increases the impact of credential compromise.

C. It makes password hashing impossible.

D. It eliminates the need for audit logs.

Correct Answer: B. It increases the impact of credential compromise.

Question 6

Which technology is primarily an authorization framework for delegated access rather than an authentication protocol?

A. OAuth 2.0

B. Kerberos

C. LDAP

D. SAML

Correct Answer: A. OAuth 2.0

Question 7

What does OpenID Connect add to OAuth 2.0?

A. A physical network layer

B. An identity and authentication layer

C. A password-hashing algorithm

D. A directory naming hierarchy

Correct Answer: B. An identity and authentication layer

Question 8

What is a defining feature of Kerberos?

A. It uses service tickets issued by a trusted authority.

B. It stores every user password in each application.

C. It is used only for biometric authentication.

D. It eliminates the need for synchronized clocks.

Correct Answer: A. It uses service tickets issued by a trusted authority.

Question 9

Which control most directly reduces the risk of excessive access after an employee changes jobs?

A. Periodic and event-driven access reviews

B. Longer screen-lock timers

C. Disabling all audit logging

D. Using shared accounts for each department

Correct Answer: A. Periodic and event-driven access reviews

Question 10

Why can SSO increase the consequences of identity-provider compromise?

A. It prevents applications from using authorization policies.

B. One compromised authentication service may provide access to many connected applications.

C. It requires every application to store plaintext passwords.

D. It removes the need for MFA.

Correct Answer: B. One compromised authentication service may provide access to many connected applications.