SAML IdP and OIDC OP with short-lived pre-selector chain

This document describes how to configure SAML IdP and OIDC OP SSO flows in Fortified ID Access where both protocol entry points use a shared Selector for authentication method selection.

---

Overview

This use case describes how to configure predictable authentication method selection when both SAML IdP and OIDC OP flows are configured in the same environment.

In combined SSO scenarios, the protocol authenticator does not perform the actual user identification. The SAML IdP or OIDC OP acts as the protocol entry point, while the configured authentication chain performs the actual authentication.

To make the flow work correctly, configure a short-lived Chain authenticator before the Selector. The chain uses expiry: PT1S and contains the Selector as its required next step.

---

Prerequisite

• This use case assumes that you have good knowledge of the product in question.
• Fortified ID Access installed and configured with the default configuration.
• A SAML IdP flow and an OIDC OP authorization flow configured in the same environment.
• One shared Selector that presents the available authentication methods.
• The examples in this guide contain partial configuration snippets intended to explain the authentication flow. A complete configuration requires additional authenticators, modules, relying parties, SAML applications, claims, assertions, and environment-specific settings.

---

Step 1 - Common configuration (pre-selector chain)

Configure the SAML IdP and OIDC OP flows to point to a short-lived Chain that immediately executes the Selector.

Configuration

Create a Chain authenticator before the Selector.

• type: Chain
• expiry: PT1S
• The chain contains the Selector as a required authenticator.

Inline example

{
  "id": "pre_selector_chain",
  "type": "Chain",
  "config": {
    "base_path": "/access/authn",
    "expiry": "PT1S",
    "chain": [
      {
        "id": "selector",
        "required": true,
        "order": 1
      }
    ]
  }
}

The short expiry ensures that this wrapper step does not create a long-lived completed state before the Selector is evaluated.

---

Step 2 - SAML IdP authentication

The SAML IdP authenticator acts as the protocol entry point for SAML SP applications.

Configuration

Configure the SAML IdP chain to reference pre_selector_chain.

Inline example

{
  "id": "saml_idp",
  "type": "SAMLIDP",
  "config": {
    "base_path": "/access/authn",
    "context_path": "/access/authn/chain",
    "internal_http_destination": "http_saml",
    "force_re_auth": false,
    "idp": "${globals.saml_idp_entityid}",
    "chain": {
      "id": "pre_selector_chain",
      "required": true,
      "order": 1
    },
    "assertion_config": "@include_as_array:assertions_saml_idp/*.json"
  }
}

The SAML IdP receives the SAML authentication request, delegates actual authentication to the pre-selector chain, and issues the assertion after successful authentication.

---

Step 3 - OIDC OP authentication

The OIDC authorization code flow authenticator acts as the protocol entry point for OIDC Relying Parties.

Configuration

Configure the OIDC OP authorization flow to reference pre_selector_chain.

Inline example

{
  "id": "oidc_op",
  "type": "OIDCAuthCodeFlow",
  "config": {
    "base_path": "/access/authn",
    "failure_location": "/authn/failure.html",
    "chain": [
      {
        "id": "pre_selector_chain",
        "required": true,
        "order": 1
      }
    ],
    "keystore": "@include:oidc/keystore.json",
    "rps": "@include_as_array:oidc/rps/*.json"
  }
}

The OIDC OP receives the authorization request, delegates actual authentication to the pre-selector chain, and issues the authorization code and tokens after successful authentication.

---

Step 4 - Selector (authentication method selection)

The Selector presents the available authentication methods to the user.

Configuration

• expiry: PT1S
• lazy_expiry: true
• Options can be filtered using include_expr, for example based on exported application or relying-party properties.

Inline example

{
  "id": "selector",
  "type": "Selector",
  "config": {
    "base_path": "/access/authn",
    "expiry": "PT1S",
    "lazy_expiry": true,
    "webroot_dir": "web/authenticator/selector",
    "options": [
      {
        "id": "uid_pwd",
        "target": "uid_pwd",
        "label": "Username & Password",
        "logo": "assets/svg/uid_pwd.svg",
        "include_expr": "mv.containsAny(exports.app_tag, 'uid')"
      },
      {
        "id": "bankid",
        "target": "bankid",
        "label": "BankID",
        "logo": "assets/svg/bankid.svg",
        "include_expr": "mv.containsAny(exports.app_tag, 'bankid')"
      }
    ]
  }
}

The Selector remains responsible for presenting and re-selecting valid authentication methods. The pre-selector chain controls how the SAML IdP and OIDC OP flows enter the Selector.

---

Authentication flow (Mermaid diagram)

sequenceDiagram
    autonumber
    actor User
    participant SAMLSP as SAML SP application
    participant OIDCRP as OIDC Relying Party
    participant SAMLIDP as SAML IdP
    participant OIDCOP as OIDC OP
    participant Chain as pre_selector_chain<br/>Chain, expiry PT1S
    participant Selector as Selector<br/>expiry PT1S, lazy_expiry true
    participant Method as Selected authenticator<br/>UID, BankID, or other

    alt SAML login
        User->>SAMLSP: Open SAML application
        SAMLSP->>SAMLIDP: Send SAML AuthnRequest
        SAMLIDP->>Chain: Execute configured chain
    else OIDC login
        User->>OIDCRP: Open OIDC application
        OIDCRP->>OIDCOP: Send authorization request
        OIDCOP->>Chain: Execute configured chain
    end

    Chain->>Selector: Execute selector as required step
    Selector->>Selector: Evaluate available options
    Selector->>User: Present matching authentication methods
    User->>Selector: Select authentication method
    Selector->>Method: Redirect to selected authenticator
    Method->>User: Perform authentication
    User->>Method: Complete authentication
    Method->>Selector: Return completed authentication
    Selector->>Chain: Complete selector step

    alt Return to SAML
        Chain->>SAMLIDP: Authentication completed
        SAMLIDP->>SAMLSP: Issue SAML assertion
    else Return to OIDC
        Chain->>OIDCOP: Authentication completed
        OIDCOP->>OIDCRP: Issue authorization code and tokens
    end

---

SSO behaviour across protocol flows

This use case supports SSO behavior across both SAML and OIDC applications while keeping authentication method selection predictable.

Existing matching authentication

If the user already has a valid authentication session for a method that is still allowed by the Selector:

• The Selector can re-select the previously used option when lazy_expiry: true is enabled.
• The user is not prompted unnecessarily.
• The SAML IdP or OIDC OP can complete the protocol response using the existing valid authentication context.

Existing non-matching authentication

If the user has an existing session, but the previously used method is not allowed for the target application or relying party:

• The Selector must not silently reuse that method.
• The user is prompted to select or complete an allowed authentication method.
• Stronger or application-specific authentication requirements remain enforced.

Expired pre-selector chain

The pre-selector chain itself is intentionally short-lived:

• It does not act as the long-lived SSO decision point.
• It provides a controlled handoff from SAML IdP or OIDC OP to the Selector.
• The selected authentication method remains the meaningful authentication state.

---

Summary

By combining:

• SAML IdP and OIDC OP protocol authenticators
• A shared short-lived pre-selector Chain (expiry: PT1S)
• A Selector with expiry: PT1S and lazy_expiry: true
• Application- or relying-party-specific filtering of available authentication methods

Fortified ID Access can support predictable SSO behavior across SAML and OIDC flows.

This approach provides:

• A consistent entry pattern for both SAML IdP and OIDC OP flows
• Controlled handoff into the Selector
• Reduced risk of unintended completed-state reuse
• Flexible authentication method selection across mixed protocol applications