SAML SP application with enforced authentication method (BankID / UID)

This document describes how to configure a SAML Service Provider (SP) application in Fortified ID that requires a specific authentication method, such as BankID, or allows multiple authentication methods (e.g. UID + BankID).

---

Overview

This use case describes how to configure a SAML Service Provider (SP) application to enforce a specific authentication method (for example BankID), or allow multiple authentication methods (UID and BankID), using standard Access authenticators and selectors.

---

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
• The examples in this guide contain partial configuration snippets intended to explain the authentication flow. A complete configuration requires additional authenticators, modules, and environment-specific settings.

Step 1 – Common configuration (expiry)

All authenticators in this flow use a very short-lived session to ensure that authentication state is controlled exclusively by the flow logic.

Configuration

Set the following property on all relevant authenticators:

• expiry: PT1S

This configuration applies to:

• SAML IdP authenticator
• Selector authenticator

Using a 1-second expiry ensures that no long-lived session is created before authentication method selection and authentication have completed.

---

Step 2 – SAML IdP authentication

The SAML IdP authenticator acts as the protocol entry point for all SAML SP applications in this use case.

Configuration

Inline example

{
  "id": "idp1",
  "type": "SAMLIDP",
  "config": {
    "base_path": "/access/authn",
    "context_path": "/access/authn/chain",
    "internal_http_destination": "http_saml",
    "expiry": "PT1S",
    "force_re_auth": false,
    "idp": "${globals.saml_idp1_idp_entityid}",
    "chain": {
      "id": "auth01",
      "required": true,
      "order": 1
    },
    "assertion_config": "@include_as_array:assertions_idp1/*.json"
  }
}

The short expiry (PT1S) ensures that control is immediately passed to the selector.

---

Step 3 – Selector (authentication method selection)

A selector is used to control which authentication method(s) are available for a given application.

Configuration

• expiry: PT1S
• lazy_expiry: true

Inline example

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

---

Step 4 – Authentication Methods

UID Authentication

The UID authenticator is used for username/password‑based authentication (for example LDAP UID/password).

This authenticator is only reachable if:

• The selector includes the UID option
• The application is tagged with uid

BankID Authentication

The BankID authenticator is used for strong electronic identification.

This authenticator is only reachable if:

• The selector includes the BankID option
• The application is tagged with bankid

---

Step 5 – SAML Application Configuration

The SAML SP application must define app_tag values that control which authentication methods are allowed.

Application Properties

Set the app_tag property in the SAML application configuration.

See: SAML Application – Properties

---

Application Scenarios

Application Requiring Only BankID

"app_tag": ["bankid"]

Result:

• Selector shows only BankID
• UID authentication is not available

---

Application Allowing UID and BankID

"app_tag": ["uid", "bankid"]

Result:

• Selector shows both UID and BankID
• User can choose either authentication method

---

Authentication flow (textual diagram)

The complete authentication flow is executed in the following order:

1. SAML SP → SAML IdP
   • Entry via the SAML IdP authenticator
   • Session created with expiry: PT1S
2. Selector
   • Selector is executed
   • Determines available options based on exports.app_tag
3. Selector options
   • UID option shown if app_tag contains uid
   • BankID option shown if app_tag contains bankid
4. Authentication execution
   • User is redirected to the selected authenticator (UID or BankID)
5. Assertion issued
   • Successful authentication returns control to the SAML IdP
   • Assertion is sent back to the SAML SP application

---

SSO behaviour across applications

This use case supports Single Sign-On (SSO) behavior across applications depending on the authentication method used.

BankID-first scenario

• If a user authenticates with BankID to an application that is tagged with only bankid
• And the user later accesses an application that allows both uid and bankid

Then:

• SSO is performed
• No additional authentication is required
• The existing BankID authentication is reused

Mixed-method application scenario

When a user first accesses an application that allows both UID and BankID:

• If BankID is selected:
  • SSO will be performed when accessing an application that requires only BankID
• If UID is selected:
  • No BankID session exists
  • When accessing an application that requires only BankID, the user will be prompted to authenticate with BankID

This behavior ensures that:

• Strong authentication requirements (BankID-only applications) are always enforced
• SSO is only applied when the authentication context matches the target application’s requirements

---

Summary

By combining:

• SAML IdP authentication
• Short‑lived sessions (expiry: 1s)
• A selector with lazy_expiry: true
• Application‑specific app_tag values

You can precisely control which authentication methods are available for each SAML SP application while reusing the same authentication flow across multiple applications.

This approach provides:

• Strong separation of application requirements
• Centralized authentication logic
• Flexible support for both single‑method and multi‑method authentication scenarios