Authentication Mechanisms¶

This document gives an overview of every authentication mechanism currently in use across the platform, followed by a per-mechanism sequence diagram.

All hostnames use the ENV placeholder (e.g. api.ENV.ianwilliams.co.uk).

Mechanisms at a glance¶

#	Mechanism	Consumers	Entry point	Validated by
1	Entra App Registration token	Accent, Stonewater	`accent.ENV.ianwilliams.co.uk` (Client Connector)	Client Connector itself, against Entra ID
2	API key	Anchor, NorthStar	`api.ENV.ianwilliams.co.uk` (APISIX)	APISIX, against Key Vault
3	Auth Service (Keycloak) client credentials → JWT	IFS	`api.ENV.ianwilliams.co.uk` (APISIX)	APISIX, against Auth Service
4	Entra App Registration + Entra group check	Order Portal, Roc Portal (internal users)	Portal sign-in	Entra ID
5	Auth Service (Keycloak) OIDC login	Media Portal / iw-roc (internal + external users), Proteus UI (internal users)	Portal sign-in	Auth Service, brokering to Entra ID / Brighter Places / Worthing IdPs
6	Entra ID SSO for third-party SaaS (new)	IFS Cloud UI (OIDC, App Registration), Dayforce (SAML, Enterprise App) — internal staff	Application sign-in	Entra ID

Overview¶

flowchart LR
    subgraph external["External Clients"]
        accent["Accent / Stonewater"]
        anchor["Anchor / NorthStar"]
        ifs["IFS"]
        extUsers["Media Portal external users"]
    end

    subgraph internal["Internal Users"]
        staff["Ian Williams staff"]
    end

    subgraph portals["Portals"]
        orderPortal["Order Portal"]
        rocPortal["Roc Portal"]
        mediaPortal["Media Portal (iw-roc)"]
        proteusUi["Proteus UI (dev portal)"]
    end

    subgraph clientIdps["Client IdPs"]
        bp["Brighter Places IdP"]
        worthing["Worthing IdP"]
    end

    subgraph saas["Third-Party SaaS (new, staff SSO)"]
        ifsCloud["IFS Cloud UI"]
        dayforce["Dayforce"]
    end

    subgraph tenant["Ian Williams Azure Tenant"]
        entra["Entra ID<br/>(App Registrations + Groups)"]
        kv["Key Vault<br/>(API keys)"]

        subgraph cae["Azure Container App Environment"]
            apisix["APISIX API Gateway<br/>api.ENV.ianwilliams.co.uk"]
            keycloak["Auth Service (Keycloak)"]
            connector["Client Connector<br/>accent.ENV.ianwilliams.co.uk"]
            invoice["Invoice Service"]
            appointment["Appointment Service"]
            orderSvc["Order Service"]
            media["Media Service"]
            proteus["Proteus"]
        end
    end

    %% 1. Entra App Registration token (Accent / Stonewater)
    accent -->|"1: get token"| entra
    accent -->|"2: request + Bearer token"| connector
    connector -.->|"validate token"| entra

    %% 2. API key (Anchor / NorthStar)
    anchor -->|"API request (key shared offline)"| apisix
    apisix -.->|"verify API key"| kv
    apisix -->|"route"| invoice
    apisix -->|"route"| appointment
    apisix -->|"route"| orderSvc
    apisix -->|"route"| media

    %% 3. Keycloak client credentials (IFS)
    ifs -->|"1: client id/secret"| keycloak
    ifs -->|"2: request + Bearer JWT"| apisix
    apisix -.->|"validate JWT"| keycloak
    apisix -->|"route"| proteus

    %% 4. Internal portals via App Registration + Entra group
    staff --> orderPortal
    staff --> rocPortal
    orderPortal -.->|"App Reg + group check"| entra
    rocPortal -.->|"App Reg + group check"| entra

    %% 5. Portals via Auth Service
    staff --> mediaPortal
    staff --> proteusUi
    extUsers --> mediaPortal
    mediaPortal -->|"OIDC"| keycloak
    proteusUi -->|"OIDC"| keycloak

    %% IdP federation
    keycloak -.->|"broker (internal users)"| entra
    keycloak -.->|"broker"| bp
    keycloak -.->|"broker"| worthing

    %% 6. Third-party SaaS SSO via Entra ID
    staff --> ifsCloud
    staff --> dayforce
    ifsCloud -.->|"OIDC (App Registration)"| entra
    dayforce -.->|"SAML (Enterprise App)"| entra

    %% Edge colours per mechanism
    linkStyle 0,1,2 stroke:#1f77b4,stroke-width:2px
    linkStyle 3,4,5,6,7,8 stroke:#e8821a,stroke-width:2px
    linkStyle 9,10,11,12 stroke:#2ca02c,stroke-width:2px
    linkStyle 13,14,15,16 stroke:#9467bd,stroke-width:2px
    linkStyle 17,18,19,20,21 stroke:#d62728,stroke-width:2px
    linkStyle 22,23,24 stroke:#7f7f7f,stroke-width:2px
    linkStyle 25,26,27,28 stroke:#17becf,stroke-width:2px

Open in mermaid.live

Edge colour legend:

Blue — Entra App Registration token (Accent, Stonewater)
Orange — API key via APISIX (Anchor, NorthStar)
Green — Auth Service client credentials / JWT (IFS)
Purple — App Registration + Entra group (Order Portal, Roc Portal)
Red — Auth Service OIDC login (Media Portal, Proteus UI)
Grey — Identity provider federation (Auth Service brokering)
Teal — Entra ID SSO for third-party SaaS (IFS Cloud, Dayforce)

Dashed arrows are validation/brokering calls; solid arrows are the request path.

1. Entra App Registration token — Accent, Stonewater¶

Accent and Stonewater authenticate against an App Registration in our tenant and call the Client Connector directly. The connector validates the token itself; APISIX is not in the path.

sequenceDiagram
    participant C as Accent / Stonewater
    participant E as Entra ID<br/>(App Registration)
    participant CC as Client Connector<br/>accent.ENV.ianwilliams.co.uk

    C->>E: Client credentials grant
    E-->>C: Access token
    C->>CC: API request + Bearer token
    CC->>CC: Validate token against Entra ID<br/>(signature, audience)
    CC-->>C: Response

Open in mermaid.live

2. API key — Anchor, NorthStar¶

Anchor and NorthStar hold an API key stored in a Key Vault in our tenant. The key is generated by us and shared with the client manually, offline — there is no runtime issuance step. APISIX intercepts their requests, verifies the key against Key Vault, and routes to the relevant downstream service based on its routing config.

sequenceDiagram
    participant C as Anchor / NorthStar
    participant G as APISIX<br/>api.ENV.ianwilliams.co.uk
    participant KV as Key Vault
    participant S as Downstream service<br/>(Invoice / Appointment / Order / Media)

    Note over C,KV: API key generated and shared manually offline<br/>(no runtime issuance step)
    C->>G: API request + API key
    G->>KV: Verify API key
    KV-->>G: Key valid
    G->>S: Forward request (config-based routing)
    S-->>G: Response
    G-->>C: Response

Open in mermaid.live

3. Auth Service client credentials → JWT — IFS¶

IFS has a client id/secret registered in the Auth Service (Keycloak). They first obtain a JWT (including permissions) from the Auth Service, then call APISIX with it. APISIX recognises the bearer-token mechanism, validates the JWT with the Auth Service, and forwards to Proteus.

sequenceDiagram
    participant C as IFS
    participant A as Auth Service<br/>(Keycloak)
    participant G as APISIX<br/>api.ENV.ianwilliams.co.uk
    participant P as Proteus

    C->>A: Token request (client id/secret)
    A-->>C: JWT (includes permissions)
    C->>G: API request + Bearer JWT
    G->>A: Validate JWT
    A-->>G: Token valid
    G->>P: Forward request
    P-->>G: Response
    G-->>C: Response

Open in mermaid.live

4. App Registration + Entra group — Order Portal, Roc Portal¶

Internal-only portals. Sign-in goes through an App Registration in our tenant; access is granted only if the user belongs to the required Entra group.

sequenceDiagram
    participant U as Internal user
    participant P as Order Portal / Roc Portal
    participant E as Entra ID<br/>(App Registration)

    U->>P: Open portal
    P->>E: Redirect to sign-in
    E->>E: Authenticate user +<br/>check Entra group membership
    E-->>P: Token (only if user is in required group)
    P-->>U: Access granted

Open in mermaid.live

These portals authenticate via the Auth Service (Keycloak), which brokers to the user's identity provider: Entra ID for internal users, Brighter Places or Worthing IdPs for Media Portal external users. Proteus UI is internal-only, so it always brokers to Entra ID.

sequenceDiagram
    participant U as User<br/>(internal or external)
    participant P as Media Portal / Proteus UI
    participant A as Auth Service<br/>(Keycloak)
    participant I as IdP<br/>(Entra ID / Brighter Places / Worthing)

    U->>P: Open portal
    P->>A: OIDC redirect
    A->>I: Broker to user's IdP
    I-->>A: User authenticated
    A-->>P: Token
    P-->>U: Access granted

Open in mermaid.live

6. Entra ID SSO for third-party SaaS — IFS Cloud, Dayforce (new)¶

New third-party services use Entra ID directly for Ian Williams staff SSO. IFS Cloud (the UI our users will use) signs in via OIDC against an App Registration in our tenant; Dayforce signs in via SAML against an Enterprise Application.

IFS Cloud — OIDC¶

sequenceDiagram
    participant U as Ian Williams staff
    participant S as IFS Cloud UI
    participant E as Entra ID<br/>(App Registration)

    U->>S: Open IFS Cloud
    S->>E: OIDC redirect to sign-in
    E->>E: Authenticate user (corporate credentials)
    E-->>S: ID token
    S-->>U: Signed in

Open in mermaid.live

Dayforce — SAML¶

sequenceDiagram
    participant U as Ian Williams staff
    participant S as Dayforce
    participant E as Entra ID<br/>(Enterprise Application)

    U->>S: Open Dayforce
    S->>E: SAML AuthnRequest
    E->>E: Authenticate user (corporate credentials)
    E-->>S: SAML assertion
    S-->>U: Signed in

Open in mermaid.live

Authentication Mechanisms¶

Mechanisms at a glance¶

Overview¶

1. Entra App Registration token — Accent, Stonewater¶

2. API key — Anchor, NorthStar¶

3. Auth Service client credentials → JWT — IFS¶

4. App Registration + Entra group — Order Portal, Roc Portal¶

5. Auth Service OIDC login — Media Portal (iw-roc), Proteus UI¶

6. Entra ID SSO for third-party SaaS — IFS Cloud, Dayforce (new)¶

IFS Cloud — OIDC¶

Dayforce — SAML¶