Identity & Access Management (IAM): MFA, RBAC & Federation

Identity is the new enterprise perimeter. In an era where applications are distributed across hybrid clouds and accessed by remote workforces, controlling who can access which resources under what conditions is the primary defensive barrier against catastrophic breaches. According to Verizon Data Breach Investigations Reports, over 80% of web application breaches involve stolen, compromised, or brute-forced credentials.

In this lesson, we examine the four pillars of IAAA, mathematically derive the Time-Based One-Time Password (TOTP) algorithm (RFC 6238), contrast RBAC vs. ABAC authorization models, and analyze modern identity federation with OAuth 2.0 with PKCE and SAML 2.0.

The IAAA Security Framework#

Modern identity architectures enforce four distinct sequential phases:

1. Identification: Stating who you claim to be (e.g., presenting a username, email address, or client ID). Identification is unverified.
2. Authentication: Proving that you are indeed who you claim to be by presenting valid authentication factors.
3. Authorization: Evaluating permissions to determine what specific operations, records, or APIs the authenticated identity is permitted to execute.
4. Accounting (Auditing): Recording an immutable chronological audit trail of all actions, logins, resource accesses, and privilege changes.

Multi-Factor Authentication: The Three Factors#

Authentication mechanisms are grouped into three classic categories:

• Factor 1: Something You Know: Passwords, passphrases, PINs (vulnerable to phishing, credential stuffing, and keylogging).
• Factor 2: Something You Have: Hardware security keys (YubiKey FIDO2), smart cards, software authenticator apps (TOTP), SMS OTP codes (vulnerable to SIM swapping).
• Factor 3: Something You Are: Biological attributes: fingerprint scans, retina/iris scans, facial geometry.

True MFA Rule: True Multi-Factor Authentication requires factors from at least two distinct categories. Prompting a user for a password followed by their mother's maiden name is two-step verification, but it is not MFA (both belong to "Something You Know").

Mathematical Derivation of TOTP (RFC 6238)#

Software authenticator applications (Google Authenticator, Authy, 1Password) generate rotating 6-digit codes every 30 seconds using the Time-Based One-Time Password (TOTP) algorithm:

Step 1: Calculate the Time Counter T#

The time step counter T is computed as the number of time intervals X (standard X = 30 seconds) that have elapsed since the Unix epoch (January 1, 1970 UTC):

T = ⌊(CurrentUnixTime - T_0) / X⌋
where T_0 = 0 and X = 30 seconds

For instance, at Unix timestamp 1,700,000,000:

T = ⌊1,700,000,000 / 30⌋ = ⌊56,666,666.666...⌋ = 56,666,666.

Step 2: Compute HMAC-SHA1 Hash#

The server and client share a pre-shared secret key K (exchanged via QR code during initial registration). The system calculates a 20-byte HMAC-SHA1 hash over the 8-byte big-endian representation of time step T:

HS = HMAC-SHA1(K, T)   (produces a 20-byte hash: Byte 0 to Byte 19)

Step 3: Dynamic Truncation#

To convert the 20-byte cryptographic hash into a human-readable 6-digit number, RFC 4226 specifies dynamic truncation:

1. Extract the low-order 4 bits of the last byte (Byte 19):

```

Offset = Byte[19] & 0x0F (yields an integer between 0 and 15)

```

1. Read a 4-byte big-endian integer starting at index Offset:

```

BinaryCode = ((Byte[Offset] & 0x7F) << 24) |

((Byte[Offset + 1] & 0xFF) << 16) |

((Byte[Offset + 2] & 0xFF) << 8) |

(Byte[Offset + 3] & 0xFF)

```

1. Take the integer modulo 10^6:

```

TOTP_Code = BinaryCode mod 1,000,000

```

This produces an exact 6-digit integer synchronized between the user's phone and the authentication server without transmitting codes across the network!

Authorization Models: RBAC vs. ABAC#

Once authenticated, authorization models govern access rights:

+------------------------------------+------------------------------------+
| Role-Based Access Control (RBAC)   | Attribute-Based Access Control (ABAC)
+------------------------------------+------------------------------------+
| Maps users to static roles.        | Evaluates dynamic boolean policies.|
| Roles map directly to permissions. | Considers Subject, Action, Resource|
| Static, simple to administer.      | and Environmental context.         |
| Suffers from "Role Explosion".     | Highly granular and scalable.      |
+------------------------------------+------------------------------------+

ABAC Policy Example#

An ABAC policy engine evaluates:

Permit IF:
  Subject.Department == "Engineering" AND
  Resource.Classification == "Confidential" AND
  Action == "Read" AND
  Environment.Time BETWEEN "08:00" AND "18:00" AND
  Environment.DeviceHealth == "Compliant" AND
  Environment.SourceCountry == "United States"

Federation: OAuth 2.0 with PKCE#

In modern single-page applications (SPAs) and mobile apps, securing API access utilizes the OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE) (RFC 7636):

Client App                                              Auth Server (IdP)
    |                                                           |
    | 1. Generates code_verifier (random secret)               |
    |    Computes code_challenge = Base64(SHA-256(verifier))   |
    |                                                           |
    | --- 2. Auth Request with code_challenge ----------------> |
    | <--- 3. Returns Authorization Code ---------------------- |
    |                                                           |
    | --- 4. Token Request with Code + code_verifier ---------> |
    |                                                           | [ Verifies: SHA256(verifier) ]
    |                                                           | [ == stored code_challenge ]
    | <--- 5. Issues Access Token (JWT) + ID Token ------------ |

Why PKCE is mandatory: In public clients (React apps, mobile iOS/Android apps), an attacker on the device could intercept the authorization code via custom URI scheme hijacking. Because the attacker does not possess the secret code_verifier stored in memory, they cannot exchange the stolen code for an access token!

Checkpoint Questions & Practice Exercises#

Question 1: An organization wants to prevent adversary-in-the-middle (AiTM) phishing proxies (such as Evilginx2) that steal session cookies and TOTP codes. Which authentication technology completely neutralizes this attack?

• Answer: FIDO2 / WebAuthn Hardware Security Keys (Passkeys). FIDO2 cryptographically binds the authentication assertion to the origin URL (the browser's TLS channel). If an attacker proxies the traffic through a phishing domain like evil-devthesis.com, the hardware key signs evil-devthesis.com, which the legitimate server (devthesis.com) rejects.

Question 2: Explain the phenomenon of "Role Explosion" in RBAC architectures and how migrating to ABAC solves it.

• Answer: In large enterprises, creating distinct roles for every permutation of department, geographic region, and job level results in thousands of overlapping roles (e.g., Engineering-US-Senior, Engineering-EU-Junior), making governance unmanageable. ABAC solves this by maintaining a minimal set of base roles and evaluating dynamic attributes (location, citizenship, compliance status) at runtime.