Chapter 13 — Identity and access | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["13.1 Principals, credentials and sessions"]
  N2["13.2 Federation"]
  N3["13.3 Life cycle"]
  N4["13.4 Revocation versus rotation versus disablement"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["13.1 Principals, credentials and sessions"]
  N2["13.2 Federation"]
  N3["13.3 Life cycle"]
  N4["13.4 Revocation versus rotation versus disablement"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]

[Learning outcomes and connection]
    |
    v
[13.1 Principals, credentials and sessions]
    |
    v
[13.2 Federation]
    |
    v
[13.3 Life cycle]
    |
    v
[13.4 Revocation versus rotation versus disablement]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes and connection

You will be able to (1) distinguish principal, credential, session and role; (2) trace an identity's life cycle through a federated sign-in; (3) compare session revocation, credential rotation and account disablement; and (4) choose the right combination for a given compromise. Chapter 6 modelled access as a graph; this chapter explains what the edges are made of. Chapter 31 applies it to cloud incidents.

13.1 Principals, credentials and sessions

A principal is an entity that can be authenticated: a person's account, a service account, a workload identity. A credential proves the principal's identity: password, private key, certificate, hardware token, client secret. A session is the state created after successful authentication, usually represented by a token or cookie with a lifetime. A role or group bundles permissions. Incidents can compromise any of these separately: a stolen session cookie gives access without the password; a stolen password without MFA gives new sessions; a stolen client secret gives a service's access indefinitely.

13.2 Federation

In federation, an identity provider (IdP) authenticates the user and issues an assertion or token (for example SAML assertions, or OpenID Connect ID tokens with OAuth 2.0 access tokens) that a relying service accepts. The service then often creates its own session. Consequences for response: the IdP's sign-in log shows authentication; the service's log shows use; revoking at the IdP may not end an existing service session; and access tokens may remain valid until they expire unless the service checks revocation. NIST SP 800-63B gives guidance on authenticators and reauthentication; consult its current revision.

13.3 Life cycle

Identities are created (joiner), changed (mover) and removed (leaver). Each stage leaves records and creates risk: orphaned accounts of leavers, accumulated permissions of movers, service accounts with no owner.

Each stage should trigger a review. A joiner gets only the access the role needs; a mover loses access from the previous role; a leaver's account is disabled on the last day and its sessions revoked. Service accounts need a named owner and a review date, because they never leave on their own. The svc-reports example shows the risk: a client secret for a service account can remain valid for as long as nobody rotates it, and the question of who could read it has no answer without an owner who knows where it is stored.

13.4 Revocation versus rotation versus disablement

Session revocation ends current sessions; the credential still works for new sign-ins.
Credential rotation changes the secret; existing sessions may continue.
Account disablement blocks new authentication; depending on the system, existing tokens may survive until expiry. Effective containment usually combines them in an order: disable or rotate to stop new sessions, revoke sessions and refresh tokens to stop current ones, then verify with logs that no new activity appears. For service accounts, every step risks breaking the service that uses the credential.

13.5 Worked example (synthetic): a federated service-account sign-in

Fictional. Harbourline's reporting service svc-reports authenticates to the cloud IdP with a client secret. At 03:40 the IdP logs a token issuance for svc-reports from an address outside the usual cloud range; at 03:42 the analytics API logs a bulk query by svc-reports.

Trace: credential (client secret) → IdP authentication (03:40) → access token (lifetime 60 minutes) → API use (03:42). Containment comparison: - Revoke issued tokens: stops current use if the API checks revocation; does not stop the holder from requesting a new token with the secret. - Rotate the secret: stops new tokens; the 03:40 token may remain valid until 04:40. - Disable the service principal: stops new tokens; breaks the nightly report. Chosen sequence (with owner approval): add a new secret and update the reporting job; remove the old secret; revoke tokens; restrict the principal to known source ranges if the platform supports it; monitor for authentication failures with the old secret (which would show the attacker still trying). Questions that remain: where was the secret stored and who could read it?

13.6 Common errors and limits

Resetting a password and assuming the attacker is out while sessions and tokens live on.
Forgetting MFA re-registration: an attacker may have added their own authenticator.
Disabling service accounts without checking dependants.
Platform behaviour varies; verify revocation semantics in the provider's documentation.
Rotating a secret before removing the attacker's means of reading the new one.
Assuming disablement ends an active token, when it may stay valid until expiry, as the 60-minute token issued to svc-reports at 03:40 could.
Declaring containment without watching for later use of the old credential.

Exercises — chapter 13

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX037 — Map the components. Inputs: a user's phished password used at 08:00 to sign in, with MFA approved by push at 08:01; the attacker registers a new authenticator at 08:05. Steps: list each compromised component and the containment step for each. Rubric: 3 = credential, session, MFA registration identified; steps: reset password, revoke sessions/refresh tokens, remove rogue authenticator, review changes made; 2 = misses authenticator; 1 = password only; 0 = none.

EX038 — Compare options. Steps: make a table comparing revoke, rotate and disable on: stops current sessions, stops new sessions, service impact, reversibility. Rubric: 3 = accurate table with "depends on platform" where appropriate; 2 = one error; 1 = incomplete; 0 = none.

EX039 — Secret exposure. Inputs: §13.5. Steps: list three places the client secret might have leaked from and how to check each within scope. Rubric: 3 = code repository (search history), CI/CD variables or logs (access audit), configuration on a host (file access and host logs); 2 = two; 1 = one; 0 = none.

Chapter synthesis

Separate principal, credential, session and authenticator; contain each one, in an order that prevents the attacker from following your changes, and verify by logs that no new activity appears.

Continue studying — chapter 13 of 40

← Chapter 12 · Course chapter index · Chapter 14 →

Continue to the next authored lesson.