Ochestration Engine Concepts
Context
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.
Overview
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.
Transitions
Conditions
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.)
Operators
arithmetic: greater than, less than, is, is not
others: these are computed and configured at system level: unknown, abnormal, normal, rooted etc.