Skip to main content
Skip table of contents

Ochestration Engine Concepts


Veridium ID manages identities from a directory services and integrates with multiple protocols (such as SAML, Radius, Fido) to provide strong authentication with minimum impact on the user experience.

The additions on the VID solution in terms of new authentication methods (biometric or not), user-behaviour analysis engine corroborated with the data existing on each authentication session (device, geolocation, time of request, transaction type etc.) added complexity at management level, but also opened new paths in terms of authentication session handling.

Therefore, a visual composer engine is needed in order to offer a new way to manage different user authentication scenarios. The Journey Composer will provide in the end a better user experience and cleverly orchestrated scenarios to provide the simple, smart and strong authentication we have always aimed for.


Mobile Components

Server Components

Use cases

Based on the in production scenarios, there are a number of use cases that we need to model with this new Composer.

1. Login to Citrix Storefront from Desktop device

The most basic authentication example is when accessing the Citrix StoreFront from a desktop machine. The user would be able to choose one of the following authentication methods for login: a combo of SMS & PIN code, a TOTP or FIDO. Of course, the user will have these options enabled depending on the existing enrolled methods.

After a successful authentication, the next step, invisible for the user, would be for the UBA engine to assess the user behaviour and decide to move forward. If the UBA decides that the score was high enough (confident), the user will move to the final state of the journey: Allow. Otherwise, the user will finish the authentication session with Reject status.

2. Login to Citrix Storefront from Mobile device

Another basic authentication example is when accessing the Citrix StoreFront from a mobile machine. Of course, if this scenario is thought to be equivalent to the previous one, than the device type would not matter and therefore there would be only one journey defined for Accessing the Citrix SF (no device type added on the journey selector).

The user would be able to choose any of his enrolled biometric methods (Face, 4F, TouchID etc.) and then, after a successful authentication, same as before, UBA engine will assess the user behaviour and decide to move forward to the final state: Allow or Reject.

3. Administrator login to Citrix Storefront

Another possible scenario would be to create a journey for a specific group of users, in this case Administrators. This would be needed in case that we want to be more flexible with the users in this group, allowing easier authentication if the location is known or adding an extra layer of security if the location is unknown.

4. Default authentication journey

This journey will be applied on every authentication session that didn’t select any other more specific journey.

5. Other journey - Financial transaction from Mobile device

In order to demonstrate the flexibility offered by Journey Composer, the following use case describes a financial transaction initiated from mobile device. Based on the authentication context of a session, we could for instance add conditions such as amount, receiver known, location, time of day etc. and further add branches to treat the this new conditions.

Journey Composer

A journey consists of multiple types of blocks arranged in a logical way.

  • name

  • description

  • visual blocks of different types

  • priority level (~)

Journey selector

A journey selection process takes place depending on the first block of the journey (Selector block), where specific context data can be applied: groups, device, session, time, location etc.

If multiple journeys are filtered, then the journey with the highest priority will be applied.

If there is no journey on the result of selection, then the default (global) journey will be applied.

Building blocks

The journey building blocks can be of the following types:

  • selector (only one per journey, at the beginning of the journey)

  • challenge - user interaction needed (explicit auth methods such as: Face, TouchID, TOTP etc.)

  • challenge-option - lets the user choose an auth method from a list of available ones (any authentication method, any biometric method, any non-biometric method)

  • challenge-combo - a combination of more than 1 challenges on the same level (all of them are mandatory in order to move forward)

  • transition - conditionals based on the existing context

  • allow - end the authentication session with a SUCCESS status

  • reject - end the authentication session with a FAIL status

The blocks used to add nodes in a journey should be descriptive in natural language.



The following pieces of information are found on the context of an authentication session and can be added as conditions in a journey:

  • session data (financial transaction, lost mode, access a sensitive resource etc.)

  • device (type, operating system and version, rooted or not, abnormal or not etc.

  • geolocation (country, city, abnormal or not etc.)

  • time of request (working hours, weekend or not, day or night, abnormal or not etc)

  • UBA score (general or based on various parameters like: location, time etc.)


  • arithmetic: greater than, less than, is, is not

  • others: these are computed and configured at system level: unknown, abnormal, normal, rooted etc.

JavaScript errors detected

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

If this problem persists, please contact our support.