Accounts

Veridium maintains internally the list of accounts. An account can be either imported from the external source (Active Directory) or created internally only (like administrator accounts).

Each account gets an unique internal ID in form of UUID, regardless it’s imported externally or local one.

When an account is imported from Active Directory the common details such as name, email, first, last name are filled by automatically by default and additional references like:

• the external ID

• external identity public ID (such as "S-1-5-21-1346520962-2386629273-538639937-1113")

• external status (ACTIVE, DISABLED or LOCKED_OUT)

Veridium Server has a internal accounts management policy with groups and roles.

Each account is part of one or more user groups and each group has a list of associated roles. The internal roles are used to gain access for certain internal Verridium resources.

Other fields:

• Accepted License - whether the user has accepted the license agreement. For administrators only.

• The registration and activation time of the account

• The status of the account - it can be NONE, ACTIVATION_PENDING, ACTIVE, BLOCKED, BLOCKED_BY_ADMIN

• The account’s locale (e.g: en, de, it…)

• Whether the account is a system account or not

Storage format in Elasticsearch

In Elastic, account related data is stored in two index aliases:

• accounts - holds the current state of each account (serialized as JSON) together with a compact array of history logs.

• account_history - holds each history log of an account in a separate document. It contains information about the action, the entire state of the account in that moment and the set of field changes brought by that specific action.

Accounts Index

Accounts are distributed in multiple indices, using an elasticsearch rollover policy that automatically creates and writes into a new index when the size of the current index goes beyond 50GB. The first index will be called accounts-000001, the second accounts-000002 and so on. The first index is manually created by the ElasticSearchSettingsUpdate migration task.

A document in an accounts index contains two main fields: account (holding the current state of the account) and actionLogs (compact array of history logs, NOT indexed). It can be used for searching data related to the current state of accounts.

The account field contains the following searchable fields:

Example of a document:

 {
    "id": "8b40ad7f-b077-4325-96b7-0e4f87607b6a",
    "account": {
      "id": "8b40ad7f-b077-4325-96b7-0e4f87607b6a",
      "externalId": "johndoe@veridiumid.com",
      "emailAddressInfo": "johndoe@veridiumid.com",
      "phoneNumber": "+40700000001",
      "applicationId": "AD",
      "groups": [
        "tester",
        "Administrators"
      ],
      "name": "John Doe",
      "firstName": "John Doe",
      "lastName": "John Doe",
      "domain": "dev.local",
      "commonName": "CN=John Doe,OU=Users,OU=Dev,DC=dev,DC=local",
      "registrationTime": "2022-03-08T11:51:32.411+00:00",
      "external": true,
      "externalStatus": "ACTIVE",
      "accountStatus": "ACTIVE",
      "acceptedLicense": true,
      "locale": "en",
      "deviceRecognition": true,
      "primaryProfileExtId": "S-1-5-21-1346520962-2386629273-538639937-1113",
      "primaryProfileDefId": "d2535f4f-f510-4875-8991-55974a566a69",
      "authenticationFailedCount": 0,
      "systemAccount": false
    },
    "actionLogs": [...]// NOT INDEXED
    }

Accounts History index

Account history documents are distributed in indices using time window pattern. An index for each month following the pattern veridium.account_history-YYYY-MM (veridium.account_history-2024-02).

The index is automatically created when the first account history index request is received for the current month.

Documents are never individually deleted, only the entire index gets deleted according to the lifecycle policy.

A document in the account history index contains searchable fields related to the action itself (actionId, type, time, location, authorAccountId, authorDeviceId). Also, it contains the entire state of the account in that moment (the account field, the same searchable fields as above) and a set of fieldChanges, storing all the searchable fields that have changed compared to the previous version, with their previous and current value. It can be used for searching data related to specific mutations of an account.

An example of document:

{
    "id": "e96782f2-8720-4277-89b1-c34bd491ac3f",
    "actionTime": "2024-02-27T22:13:30.925+00:00",
    "actionType": "UPDATED",
    "location": {
      "ip": "79.115.63.208",
      "countryCode": "RO",
      "countryName": "Romania",
      "regionCode": "IF",
      "regionName": "Ilfov",
      "city": "Otopeni",
      "postalCode": "075100",
      "coordinates": {
        "lat": 44.55,
        "lon": 26.0724
      },
    },
    "authorAccountId": "b974def7-bdc7-4fac-b51d-33da86848387",
    "authorDeviceId": "ssp_dc1",
    "account": {...} //the account state in the moment of the history event, has the same structure as above
    "fieldChanges": {
      "accountStatus": {
        "previousValue": "ACTIVATION_PENDING",
        "currentValue": "ACTIVE"
      },
      //... other field changes if exist
    }
  }