Skip to main content
Skip table of contents

Delegated authentication and shared accounts

This feature enables delegated authentication for specific user accounts. This means that an account can be authenticated by one or multiple designated users. To complete the authentication process, the delegated users must authenticate themselves within the same session using the configured authentication methods.

Glossary:

  • delegator, delegating user = the user that asks another user for an authentication. For example a shared device in a meeting room.

  • delegated user = the user that performs the authentication on behalf of the delegator. For example the manager that approves the shared device usage by a delegator.

Structure of Active Directory Groups

This section outlines the structure and purpose of Active Directory (AD) groups used in the delegation authentication mechanism. To facilitate delegation authentication, two types of Active Directory groups are used:

  1. Shared Accounts Group: This group contains shared user accounts (e.g., meeting room accounts, shared device accounts) that can be authenticated by multiple users.

image-20241211-080349.png

  1. Delegated Users Group: This group comprises shared accounts and their assigned delegates. Shared accounts are designed for collaborative utilization, such as meeting rooms or trading terminals. Delegated users are authorized to authenticate these shared accounts, facilitating a seamless and secure authentication process.

image-20241211-080606.png

Veridium Manager Group Administration

In Veridium Manager, you can configure shared groups and assign delegated users. To prevent unauthorized enrollment, shared accounts are excluded from the "Enroll Account" permission. Delegated users, however, can enroll their own devices.

  1. We'll define a "SharedAccounts" group, mirroring the AD group structure (note that the group name in AD needs to be the same with the group name in Veridium). This group will be designated as a "delegated group," enabling users to authenticate using delegated users. To restrict enrollment privileges, we won't assign the "Enroll Account" role to this group.

image-20241211-081206.png

  1. Besides the SharedAccounts group, we'll need to specify a group for the delegated users. This group, such as "Trading," will align with the AD structure and house the users authorized to authenticate shared accounts.

image-20241211-081543.png

We have introduced a new permission for enrollment called Enroll Account, to be able to limit access to self enrollment. The default group will have this role out of the box, just to be backward compatible.

image-20241211-081654.png

The group administration feature simplifies managing shared accounts and their delegated users. By defining shared groups, setting up delegation authentication, and controlling self-enrollment permissions, administrators can ensure secure and efficient access. Shared accounts are prevented from self-enrollment, streamlining management and focusing on delegated user enrollment.

Orchestration in the Veridium Manager

In this section we will go through step by step the configuration and orchestration of authentication for shared users.

Policy

image-20241211-102030.png

Delegate authentication policy is introduced in order to orchestrate the authentication.

Command

CODE 
"type": "AUTHENTICATION",
"executor": "FRIEND",
"authenticate": {
    "methods": [],
    "dispatch": {
        "method": "DELEGATE"
    }
}
image-20241211-090120.png

Condition

CODE 
allowed_groups := {"SharedAccounts"}
identityGroups = {identityGroup | identityGroup := input.identity.groups[_]}
count(identityGroups & allowed_groups) > 0
image-20241211-090223.png

This condition will be used in the Selector in order to trigger the delegate authentication flow. This condition is used to identify shared accounts based on their membership in the Shared Accounts group.

Selector

image-20241211-090446.png
image-20241211-090456.png

The selector uses the condition to determine whether to initiate the delegation authentication flow.. If it is a shared identity, the shared authentication flow will be triggered.
Sample export for the illustrated selector: orchestration_selector_9174d5c6-19e5-450a-91bf-d3a23eee1329.base64

Journey

image-20241211-090704.png

Journey components:

  1. Shared Account Authentication: The user enters the username of the shared account.

  2. Optional LDAP Password: If configured, the user may be prompted to enter an LDAP password.

  3. Delegation Method: The user can either:

    • Scan a Personalized QR Code: A QR code is generated and sent to the delegated user, who can scan it to authenticate the shared account.

    • Select a Delegated User: The user manually selects a delegated user and sends them a push notification or SMS to authenticate the shared account.

Sample export for illustrated journey: orchestration_journey_252c4301-0c57-4b44-91b3-832c50b297ba.base64

Enrollment

image-20241211-093714.png

Shared accounts are restricted from self-enrollment due to the absence of the "Enroll Account" permission.
Nevertheless, if assigned to a group possessing enrollment privileges, they can enroll like any other user. In essence, shared accounts are created upon their initial successful authentication, contingent on their membership in a delegated group.

Authentication

  1. Enter the username of the shared account

image-20241211-094326.png

  1. Follow the journey steps (1st step for us is to enter LDAP Password)

image-20241211-094424.png

  1. Then, we have the option to scan the personalized QR, or to delegate the session to a specific user

image-20241211-094525.png

→ Scan QR

image-20241211-094640.png

Mobile screen after QR Scan

image-20241211-095018.png

Successfully authenticated

→ Delegate specific user

image-20241211-095643.png

Selection of the delegated user

image-20241211-095700.png

Autocomplete is available for the list of the available delegated users

image-20241211-095733.png

In this example, Push Notification will be used to illustrate the mobile end of the flow.

image-20250130-095959.png
image-20250130-095717.png

image-20241211-095018.png

Successfully authenticated

Websec APIs - related to authentication delegation

  1. The cmd_delegate_authentication suppose to allow the user to select a user to delegate the authentication to. There is a new API endpoint to get the list of users configured to authorise the authentication.

NONE 
POST /enterprise/friend/GetDelegateProfiles
Content-Type: application/vnd.veridiumid.getdelegateprofilesrequest-v1+json

Request payload:
{
  "sessionId": "string",
  "profileInternalId": "string",
  "context": { ... }
}

Response payload:
{
  "profiles": [
    {
      "id": "string",
      "displayName": "string"
    }
  ],
  "error": {
    "errorDescription": "string",
    "errorCode": 0
  }
}

  1. Next send the ID of selected profile (got from the previous call) by calling the next API endpoint to indicate the handover authentication action.

CODE 
POST /enterprise/DelegateAuthentication
Content-Type: application/vnd.veridiumid.delegateauthenticationrequest-v1+json

Request payload:
{
  "memberExternalId": "string",
  "sessionId": "string",
  "profileInternalId": "string",
  "origin": "string",
  "context": {
    ...
  }
}


Response payload (SessionResponse):
{
  "deviceStatus": "ACTIVATION_REQUEST",
  "status": "string",
  "biometricAuthenticationResult": "NONE",
  "sessionId": "string",
  "journeyId": "string",
  "journeyDefinitionId": "string",
  "journeyStateName": "string",
  "accountId": "string",
  "memberDefinition": {
    "id": "string",
    "externalId": "string"
  },
  "profile": {
    "id": "string",
    "externalId": "string"
  },
  "authenticationDevice": {
    "id": "string",
    "externalId": "string",
    "description": "string"
  },
  "exploiterDevice": {
    "id": "string",
    "externalId": "string",
    "description": "string"
  },
  "expiration": 0,
  "authenticationMode": "string",
  "failReason": "string",
  "externalValues": {
    "additionalProp1": {},
    "additionalProp2": {},
    "additionalProp3": {}
  },
  "identityData": {
    "additionalProp1": {},
    "additionalProp2": {},
    "additionalProp3": {}
  },
  "identityProfileData": {
    "id": "string",
    "externalId": "string",
    "displayName": "string",
    "upn": "string"
  },
  "exploiterDeviceContext": {
    "localDateTime": "2024-12-18T08:07:30.470Z",
    "timezoneOffset": 0,
    "ip": "string",
    "location": {
      "ip": "string",
      "countryCode": "string",
      "source": "IP",
      "countryName": "string",
      "regionCode": "string",
      "regionName": "string",
      "city": "string",
      "district": "string",
      "street": "string",
      "streetNumber": "string",
      "postalCode": "string",
      "coordinates": {
        "latitude": 0,
        "longitude": 0
      },
      "accuracy": 0,
      "errorCode": 0
    },
    "userAgentRaw": "string",
    "userAgentName": "string",
    "userAgentVersion": "string",
    "userAgentDevice": "string",
    "userAgentTrustId": "string",
    "language": "string",
    "internetConnectionType": "string",
    "deviceMake": "string",
    "deviceModel": "string",
    "osName": "string",
    "osVersion": "string",
    "isRooted": true,
    "hasHardwareCryptoSupport": true,
    "serviceIdentifier": "string",
    "serviceFriendlyName": "string",
    "empty": true,
    "rooted": true
  },
  "ubaMotionOutput": {
    "answer": 0,
    "answerConfidence": "string",
    "score": 0
  },
  "ubaContextOutput": {
    "answer": 0,
    "answerConfidence": "string",
    "score": 0
  },
  "identityTokenJWT": "string",
  "ntKey": "string",
  "biometricMethods": [
    {
      "type": "string",
      "status": true,
      "retries": 0,
      "enrollmentTrackerId": "string"
    }
  ],
  "commands": [
    {
      "type": "NONE",
      "id": "string",
      "attributes": {
        "additionalProp1": {},
        "additionalProp2": {},
        "additionalProp3": {}
      }
    }
  ],
  "transactionText": "string",
  "userAgentTrustCookie": {
    "trustId": "string",
    "expirationTime": 0
  },
  "error": {
    "errorDescription": "string",
    "errorCode": 0
  }
}

  1. Next steps will handled as a usual authentication journey. The final successful complete step will assign back the session to the initial user.

Compatibility matrix for Credential Provider:

CP Version

Without Delegation command

With Delegation command

3.5.6

supported

not supported

3.6.2

not supported

3.7.3

supported

Abuse prevention for delegation flow:

  1. The abuse prevention mechanism makes use of the Settings / General / Authentication Max Retries parameter, to ensure consistency in user blocking scenarios.

  2. The delegating user will trigger the parameter counter at the delegated account selection step.
    - If the delegated account does not complete a successful authentication (this includes abandoning the session or cancelling it with “back” button), the delegating user will be blocked if the Authentication Max Retries value is reached.
    - If the delegated account completes a successful authentication, the counter is reset for the delegating user.
    - Delegated account’s failed authentications (bad credentials) will also be counted for it too, besides the delegating one - functioning as in previous versions.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close