Week5: IAM

Week-5 Identity and Access Management

Ali Jaddoa, ,

Ali.Jaddoa@roehampton.ac.uk

Date:


25/26
Week5: IAM

Operational Model of Cybersecurity

width:1OO% center


25/26
Week5: IAM

Main Questions

  • Who you are (IAM); What you can do (AC); How you access resources securely across systems (OAuth)?
    width:1OO% center

25/26
Week5: IAM

Generic Scenario

  • A project manager logs in to the company portal.
  • IAM confirms who they are with MFA.
  • Access Control lets them view project schedules but not financial data.
  • They use OAuth to access a partner’s document system without re‑entering credentials.

25/26
Week5: IAM

1. IAM ( Identity and Access Management)

2. Access control: Next Week.


25/26
Week5: IAM

IAM

A set of attributes that describe an entity (person, organisation, system, process).
width:1OO% center
Entity Person, organisation, system, session, or process.
Identity Attributes for an entity in a specific domain. Can exist in multiple domains or as multiple identities in one domain.
Digital Identity Electronic form of identity attributes.
Names & Attributes May be unique or shared, temporary or permanent, self‑defined or authority‑defined.
Identifier Unique name or value within a namespace.

25/26
Week5: IAM

Identity - Creation - Registration

  • Etymology: “Identity” = the same one as last time
  • Authentication is only possible if an identity is registered
  • Without an identity, there is no “last time” to compare against
  • Registration Methods:
    1. Identity Verification - Create a new digital identity from an existing one (e.g., passport)
    2. New Creation - Assign a new identity to a new entity (e.g., newborn baby)

25/26
Week5: IAM

Identity domains

IAM Types Diagram --------------------------------------- IAM Domains Diagram
  • A domain has a namespace with unique names.
  • A user may have:
    • Different identities in different domains.
    • One or more identities in the same domain.
  • Types of IAM Domains:
    • Siloed - One authority (e.g., corporate network).
    • Federated - Shared across services with common identity policies.
    • Centralised - Managed entirely by a single trusted authority.
    • User‑Centric - Users control their own identity and authentication.
  • Today’s focus: Siloed and Federated IAM.

25/26
Week5: IAM

A. Silo identity management

  • Each SP maintains its own user registry and authentication (SP = IdP).
  • Users need a separate account and password for each service.
    • Strong privacy - no data sharing between silos.
    • Simple for service providers to implement.
    • Multiple logins.
    • Poor scalability.
  • Still used in some contexts, but often replaced by federated IAM.
 Silo Domain Diagram

25/26
Week5: IAM

Discussion: Risks of Silo-Based IAM

Scenario
Your orginisation uses a silo-based IAM model.

  • Separate accounts for email, library, learning portal, and printing services.
  • Each system stores its own credentials.

Discussion Questions

  1. What security benefits does this model provide?
  2. How could user behaviour create risks despite these benefits?
  3. If you were the security lead, what two changes would you make to reduce the risks?

25/26
Week5: IAM

Risk Implications of Silo-Based IAM

Risk Area Implication
Isolation Breaches contained within one silo, limiting spread.
User Behaviour Password reuse across silos increases vulnerability; multiple logins weaken password practices.
Operational Poor scalability for many services; higher admin overhead.
Security Trade-Off Strong privacy protection VS. reduced usability and increased risk from poor user habits.

25/26
Week5: IAM

B. Federated Identity Management

Same user ID recognised by multiple Service Providers (SPs), with authentication handled by a separate Identity Provider (IdP).

User: Has a user ID and authenticator(s). Wants to use services from different SPs.

Service Provider (SP): Also called Relying Party. Maintains a register of user IDs. Has an agreement with one or more IdPs for user authentication.

Authentication Server (IdP): Has agreements with SPs. Provides or sells authentication as a service to SPs.

 Federated IAM Roles

25/26
Week5: IAM

B. Federated Identity Management Cont'd

  • How it works (Protocols):
    • User authenticates once via IdP.
    • IdP issues an identity token accepted by multiple SPs.
    • SPs require pre‑established trust (cryptographic keys, legal agreements).
  • Advantages:
    • Single Sign‑On (SSO) reduces password fatigue.
    • Improved usability across services.
    • Flexible architecture for many SPs.
  • Challenges:
    • Complex trust and policy setup.
    • Business costs - fees or data sharing.
 Federated Identity Management Diagram

25/26
Week5: IAM

Example: Eduroam Wi‑Fi

  1. A student logs in at their home university.
  2. The request is routed to the home institution’s IdP.
  3. The IdP confirms their identity.
  4. Access is granted at another participating university without re‑authentication.

25/26
Week5: IAM

Implementing Identity and Access Management (IAM)

IAM is implemented using open standards and protocols that provide secure, interoperable, and scalable authentication and authorisation across systems.

Layer Purpose Common Standards / Protocols
Authorisation Control Enables secure access to resources without sharing passwords. OAuth 2.0
Identity Federation Allows users to access multiple systems with a single identity (SSO). SAML 2.0, OpenID Connect (OIDC)
Directory & Policy Management Defines and enforces user identities, roles, and permissions. LDAP, RBAC, ABAC

Note: Early IAM systems relied on SAML for identity federation.
Modern IAM adopts OAuth 2.0 and OpenID Connect (OIDC) for API-driven, cloud-based environments.


25/26
Week5: IAM

Core Protocols in Practice - One more time

  1. OAuth 2.0: Delegated authorisation - “Allow this app to access my data.”
  2. SAML 2.0: XML-based authentication and federation between identity and service providers.
  3. OpenID Connect (OIDC): Adds authentication on top of OAuth 2.0 for verifying identity. Giveing a badge.

Together, these protocols enable secure Single Sign-On (SSO), API access control, and federated identity across platforms and organisations.


25/26
Week5: IAM

OAuth 2.0 - Authorisation Framework

It is an authorisation framework that allows applications to act on behalf of users without sharing their credentials.

  • Purpose: Delegated access to resources.
    • Resource Owner - The user.
    • Client - Application requesting access.
    • Resource Server - Holds protected resources (e.g., API).
    • Authorisation Server - Issues access tokens.
  • Tokens:
    • Access Token - Grants access to specific resources.
  • IAM Impact:
    • Improves security by avoiding password sharing.
    • Supports delegated access across domains.
  • Example: Letting a fitness app access your Google Fit data so it can track your steps, without ever giving the app your Google account password.
 OAuth Flow Diagram

25/26
Week5: IAM

OAuth 2.0 - In IAM Context

  • Enables secure access delegation across services.
  • Used by IAM systems to authorise third-party applications.
  • Core to API security and cloud service integration.
  • Limitation: Handles authorisation, not authentication.

OIDC builds on OAuth to verify who the user is.


25/26
Week5: IAM

OpenID Connect (OIDC) Authentication Framework

Definition: A federation protocol within Identity and Access Management (IAM) enabling secure user authentication across multiple domains.

  • Built on OAuth 2.0: Adds authentication to OAuth’s authorisation features.
  • Key Element: ID Token - a signed statement confirming user identity.
  • Role in IAM:
    • Authenticate once with an Identity Provider (IdP) to access multiple Service Providers (SPs).
    • Uses scope=openid to request an ID Token.
    • Supports Single Sign‑On (SSO), reducing password fatigue.
  • Impact:
    • Improves usability and security.
    • Requires trust agreements, access policies, and legal alignment.
 OIDC Icon

25/26
Week5: IAM

OIDC Federated Authentication - Implicit Flow
1 Client requests access from the Service Provider (SP).
2 SP shows a list of trusted Identity Providers (IdPs).
3 User selects an IdP.
4 SP redirects the client to the IdP’s authentication endpoint.
5 Client sends authentication request with scope=openid.
6 IdP prompts for login credentials.
7 User provides credentials (password, MFA, etc.).
8 Credentials sent to IdP for verification.
9 IdP validates the credentials.
10 IdP issues an ID Token to the client.
11 Client sends ID Token to the SP.
12 SP verifies the ID Token and grants access.
13 Federation trust agreements underpin the process.

25/26
Week5: IAM

Let's Try It

A JSON Web Token (JWT) consists of three parts, separated by dots:
Header Specifies the algorithm and token type. { "alg": "HS256", "typ": "JWT" }
Payload Contains the user data (claims). { "user": "Ali", "role": "Admin" }
Signature Verifies the token’s integrity and authenticity. HMACSHA256(base64(header) + "." + base64(payload), secret)

Each part is Base64URL-encoded and combined as: xxxxx.yyyyy.zzzzz

The app decodes the payload to identify the user, and verifies the signature to ensure it hasn’t been altered.


25/26
Week5: IAM

OIDC Usecase: SSO

Step Description
1 User requests a service from the Service Provider (SP).
2 SP redirects the browser to the Identity Provider (IdP) for authentication.
3 IdP displays login window (optionally with passkey challenge).
4 User presents authenticator(s) to the client (optionally with biometrics).
5 Authenticator(s) sent to IdP (optionally with passkey response).
6 IdP verifies authenticator(s) and sends ID Token to SP via client.
7 SP verifies ID Token and grants access according to policy.

25/26
Week5: IAM

OIDC: Usercases

width:1OO% center


25/26
Week5: IAM

Categorisation of Identity Federations

width:1OO% center

Namespace/idP Authentication Examples Notes
Centralised Centralised France Identité, German eID, Singpass (Singapore), Nigerian eID Namespace and IdP managed by a single authority (e.g., government). Strong legal control.
Distributed Centralised FEIDE (Norway), Eduroam User IDs defined locally (e.g., institutions) but authentication only at the home organisation.
Centralised Distributed e-Pramaan (India), Norwegian ID Portal Single namespace but multiple IdPs handle authentication. Aadhaar is main IdP in India.
Distributed Distributed Social network IdPs (Google, Apple, Facebook, Microsoft), eIDAS 2 (planned), Australian Digital ID System Multiple namespaces and multiple IdPs. Higher flexibility but more complex trust and governance.

25/26
Week5: IAM

In small groups pick a scenario to explain

width:1OO% center


25/26
Week5: IAM

dP Dependency in Identity Federation

Problem:

  • Few IdPs serve many SPs → single points of failure.
  • Example: Facebook outage (4 Oct 2021) - millions locked out for 6+ hours.

Risks:

  • Service outages across dependent SPs.
  • Vendor lock‑in to IdP policies/technology.
  • Wider impact if IdP is compromised.

Mitigation:

  • Support multiple IdPs for login.
  • Provide alternative login (local account, passkeys, government eID).
  • Distribute trust in federation design.
 IdP Dependency Diagram

Facebook Outage


25/26
Week5: IAM

Federation Protocols - Recap

Standard Description Notes
OAuth (Open Authorization) An open standard for token-based access control, allowing resources to be accessed without sharing credentials. Often used for authorisation, not authentication.
OIDC (OpenID Connect) An identity layer built on top of OAuth to provide authentication in addition to authorisation. Modern standard replacing SAML in many federations.
SAML (Security Assertion Markup Language) An XML-based standard for exchanging authentication and authorisation data between IdPs and SPs. Previously widespread; many IdPs and SPs are switching to OIDC.

25/26
Week5: IAM

Federation Protocols - Standards Challenges

Advantages Disadvantages
Better usability. Technical and legal complexity.
Allows SPs to focus on services, eliminating the need to manage authenticators. Trust requirements between actors; each actor can potentially compromise security.
Allows IdPs to gather usage pattern information for users. Privacy issues from large-scale data collection and exchange between SP and IdP.
Scales well within a sector and provides good quality authentication. Limited scalability between sectors/domains due to political and economic constraints.
A federated domain can become a silo in relation to other domains.

25/26
Week5: IAM

Lab and Activities


25/26

![bg contain right 100%](../../figures/CSop.png)

![width:1OO% height:350px center](../../figures/CybersecuritOperationStages.png)

![width:1OO% height:500px center](../../figures/scenIAM.png)

![bg contain right 100%](../../figures/scenIAM.png)

4. Would you recommend moving to a federated IAM model? Why or why not?

Left side: Descriptions

Right side: Single merged image

Left side: Text

Right side: Image

Left: Text

Right: Image

Left: Text

Right: Image