Sharing Credentials Across Multiple Authentication Methods

Overview

By default, the credentials stored in application repository (managed via DXA SCIM interface) are separate for each corresponding authentication method. That means that multiple authentication methods of even the same type have multiple different credentials (shared secrets, passwords, etc.). If there are, e.g., “TOTP 1” and “TOTP 2” authentication methods, then the shared secret for “TOTP 1” is different from the one for “TOTP 2”, is managed separately, and has different lifecycle. This reflects (not only) the typical reason for configuring multiple authentication methods of the same type which is a difference in the assurance level.

DirX Access enables to configure the authentication methods in a way that there is a shared credential across multiple authentication methods of the same type. This enables shared management at both the DXA and user sides.

Supported Methods

DirX Access currently supports this configuration for following authentication methods:

  • OTP RFC#4226 (Hash-based OTP)

  • OTP RFC#6238 (Time-based OTP)

  • Password (Basic and Form)

Configuration

The shared credentials are enabled for given authentication method (let’s call it delegatedAuthnMethod) by referencing another authentication method the credentials of which will be used (let’s call it authnMethodSource). This is done by the configuration parameter Shared credentials authentication method identifier. From then on delegatedAuthnMethod will use following configuration and credentials from the authnMethodSource for following types:

  • OTP RFC#4226

    • Authentication method configuration

      • Number of digits (challenge length)

      • Throttling value

      • Shared secret encoding

      • Look ahead (no. of tries)

    • User-specific data

      • nbLoginFailures

      • sharedSecret

      • counter

  • OTP RFC#6238

    • Authentication method configuration

      • Number of digits (challenge length)

      • Throttling value

      • Shared secret encoding

      • Time step

      • Time drift limit

    • User-specific data

      • nbLoginFailures

      • sharedSecret

      • timeDrift

    • Password

      • User-specific data

      • nbLoginFailures

      • password

The assurance level is NOT one of the configuration parameters that the methods are sharing. This is due to the fact the credentials themselves and the way they are stored at the user side is not the only determining factor for the assurance level. Another one can be, e.g., the way of transfer of the credentials. Therefore, while we recommend all the authentication methods sharing the same credentials to be configured with the same assurance level, we expect there can be scenarios in which this will not be true. Please, advocate such configuration carefully.