Identification, authentication, authorisation, accountability and federation

Cybersecurity Foundations Training Series

Learning objectives

• Distinguish identification, authentication, authorisation and accountability.

• Describe the joiner, mover and leaver identity lifecycle.

• Apply least privilege, need-to-know and periodic access review principles.

• Explain authentication factors, MFA, single sign-on and identity federation.

The purpose of IAM

Identity and Access Management, or IAM, ensures that the right identities receive the right access to the right resources for the right reasons. IAM covers people, service accounts, devices, applications and other entities that interact with organisational systems.

A mature IAM programme connects business ownership, identity proofing, account provisioning, authentication, authorisation, privileged access, logging, review and revocation. Its purpose is to support the business while reducing unauthorised access, excessive privilege and weak accountability.

Identification

Identification is the act of claiming an identity. A user enters a username, presents an identity card or provides another identifier. At this stage, the system knows the claimed identity but has not yet verified the claim.

Identification must come before authentication because the system needs an identity against which to verify the evidence.

Authentication

Authentication verifies the claimed identity. Evidence might include a password, a cryptographic security key, a smart card, a one-time code or a biometric characteristic.

Authentication supports accountability, but it does not guarantee non-repudiation by itself. Stolen credentials, shared accounts and weak logging reduce confidence in attribution. Strong authentication, unique identities, protected logs and controlled administration work together to support reliable accountability.

Authorisation

Authorisation determines what an authenticated identity is permitted to access or perform. Access decisions might be based on role, attributes, location, device condition, risk, time or an explicit access-control list.

Authorisation should enforce least privilege and need-to-know. Least privilege gives an identity only the permissions required to complete approved duties. Need-to-know limits access to the information required for a defined business purpose.

Accountability

Accountability links actions to identities and enables review. Organisations use audit logs, access reviews, database activity records, network logs, application logs, privileged session monitoring and investigation procedures.

Logs need protection against unauthorised access, alteration and deletion. They also need synchronised time, suitable retention and defined ownership so investigators can reconstruct events.

A simple banking example

A customer tells the cashier, “I am Jim.” This is identification. The customer then presents accepted evidence, such as a verified identity document and account credential. This is authentication. The bank confirms a daily withdrawal limit. This is authorisation. The transaction is recorded and later reviewed. This supports accountability.

Identity lifecycle: joiners, movers and leavers

Provisioning creates an identity and grants approved access. Approval should come from authorised owners, and high-risk access should receive additional checks.

Mover controls adjust access when duties, departments, sites or contracts change. The organisation should remove access that no longer supports the new role. Failure to remove old access creates privilege creep.

Periodic reviews verify that accounts remain active, owners remain valid and privileges remain necessary. Reviews should include privileged, shared, service and third-party accounts.

Revocation removes or disables access when employment, a contract or a business need ends. High-risk terminations require coordinated and prompt action across applications, cloud services, remote access, tokens and physical access.

Figure 1. Identity governance must address joiners, movers, reviews and leavers.

Authentication factors and MFA

Authentication factors are commonly grouped as something you know, something you have and something you are. Examples include passwords, cryptographic devices and biometrics.

No factor is automatically secure in every implementation. Biometrics cannot simply be treated as universally strongest because accuracy, presentation attacks, privacy, fallback methods and device security all matter. Passwords remain vulnerable to phishing and reuse. SMS codes improve on password-only access but remain vulnerable to social engineering and number takeover.

Multi-factor authentication combines independent factors. Phishing-resistant authenticators, such as properly implemented security keys and passkeys, provide stronger protection than methods that rely on entering a reusable or relayed code.

Figure 2. MFA combines independent factors; phishing resistance remains an important design goal.

Modern password practice

Use long, unique passwords or passphrases. Current NIST guidance requires at least 15 characters when a password is the only authentication factor and allows a minimum of eight characters when the password forms part of MFA.

Do not rely on forced mixtures of upper-case letters, lower-case letters, numbers and symbols. Screen new passwords against common and compromised values, support password managers, permit long entries and apply rate limiting.

Do not force routine password changes without evidence of compromise. Change credentials when exposure, theft, sharing or another credible risk is identified.

Single sign-on and identity federation

Single sign-on allows a user to authenticate once and access multiple approved services without repeatedly entering credentials. It improves user experience and centralises access controls, but it also increases the importance of protecting the central identity service.

Identity federation establishes trust between separate security domains. The service provider relies on an identity provider to authenticate the user and return a signed assertion or token. The service provider validates the response and applies its own authorisation decisions.

SAML commonly supports enterprise browser-based federation. OAuth 2.0 is an authorisation framework that grants limited access to protected resources. OpenID Connect adds an identity layer on top of OAuth 2.0 for user authentication. Treating OAuth alone as an authentication protocol creates design and security errors.

Figure 3. Identity federation separates the identity provider from the service provider.

IAM operational controls

Quick knowledge check

1. A user enters a username. Which IAM activity has occurred?

• A. Identification

• B. Authentication

• C. Authorisation

• D. Accountability

2. Which option combines two different authentication factors?

• A. Password and PIN

• B. Password and security key

• C. Fingerprint and face scan

• D. Two passwords

3. What is privilege creep?

• A. A slow sign-in process

• B. Access accumulating after role changes without old rights being removed

• C. A password becoming too long

• D. A token expiring during a session

4. Which statement about federation protocols is correct?

• A. OAuth 2.0 is primarily an authorisation framework

• B. SAML is a password-hashing algorithm

• C. OpenID Connect replaces access control

• D. Single sign-on removes the need for authentication

Standards and framework alignment

This lesson uses the following frameworks as complementary references. NIST provides risk and control guidance, ISO/IEC 27001 defines requirements for an information security management system, ISO 22301 addresses business continuity, and SOC 2 evaluates service-organisation controls against the AICPA Trust Services Criteria.