Core Concepts

Introduction

The purpose of this document is to simply explain the concepts around VeridiumID and how these concepts help solve our customer's problems.

Prior art

The need for a Strong and Convenient Authentication has never been more important. Security threats are becoming more complex and harder to defend against. Companies need to have Intelligence (Context) around the user identities in order to safely grant access to company resources.

The current solutions used by companies to authenticate users and defend their environments is insufficient. However, the transition to a modern and intelligent solution is an iterative process. As result, a mixed solution for authentication will be present in companies' infrastructures over next years, while they transition to a passwordless first approach.

VeridiumID provides:

• Strong and Convenient Authentication
• Easy plug & play components that integrate with your Enterprise eco-system
  • Connection to Directory Services (User repository) used by the Enterprise
  • Use of Authentication while users are accessing resources and services provided by the Enterprise.

Preamble#

AAA Standard#

From an administration point of view you would like Windows, Mac OS X and GNU/Linux to access the network from a centrally managed and maintained system. The holy grail would be a single system that maintained the user information, while still being diverse enough to accommodate the different needs (like software updates, user policies, etc.) of the different systems.

The basis for interoperability is AAA, which stands for authentication, authorization and accounting.

• Authentication: is the process of checking that the identity that is being claimed is actually legitimate
• Authorization: is the process of giving access to services
• Accounting: is keeping track of the things what actions the user took

Directory Service#

A Directory Service is comprised of a central repository that provides AAA functionality and is a critical component many systems on the network.

Each resource (e.g. users, computers) in the network is considered an object, which has an unique identifier. The relation between objects is based on their attributes and on a set of rules defined in central repository.

Interoperability#

The need for interoperability has been discussed since the early 80's.

Directory services were part of an Open Systems Interconnection (OSI) initiative for common network standards and multi-vendor interoperability. During the 1980s, the ITU and ISO created a set of standards for directory services, initially to support the requirements of inter-carrier electronic messaging and network-name lookup.

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organised set of records, often with a hierarchical structure, such as a corporate email directory.

Strong Authentication#

This (relatively) new term sometimes creates confusion (like two factor authentication or multi-factor authentication).

Authentication factors are often described as belonging to the following categories:

• Know (PIN, password)
• Have (card, token, phone)
• Are (inherent factors like biometry and user behaviour)

Today, companies are using two step authentication methods (password + extra factor like SMS, token) to mitigate security risks. These solutions can be inconvenient, hard to operate and often incur higher costs when fully rolled out. Also, some of the most popular methods, like SMS based MFA, are vulnerable to various types of attacks.

Regulations#

As a result of the industry landscape becoming more diverse and security issues becoming more and more impactful, authorities (NIST - US , EU - PSD2) have stepped in and provided regulation for different services (finance, public services, etc) and have imposed the use of strong authentication. Authorities have also provided clear definitions of different levels of assurance while implementing/adopting strong authenticators.

While additional factors can make your organisation more secure, the inconvenience of 2 step authentications can be met with resistence in some organisations. Users want an easy way to access relevant services.

VeridiumID Enterprise Role - Overview#

This section will discuss the pieces of the VeridiumID solution that make it "Easy plug & play". While the solution needs to accommodate many use cases, its most fundamental job is to provide:

• Enrolment of user identities from Directory Service
• Authentication while a user accesses resources in enterprise infrastructure (desktops, web services, etc.)

The picture below provides the logic of the connectors between VeridiumID and an Enterprise Directory Service repository.

Fig 1 - User Identities Logical View

The first action a user must complete is to create his identity in VeridiumID. This process requires connection to an external user repository (Directory Service) where there are relevant user attributes (phone number, email address, groups where he is part of) which are used to manage authentication and verification for that identity.

VeridiumID provides couple of authentication methods:

• Biometric (which it is the main authentication method proposed by Veridium)
• TOTP - Time based One Time Password
• SMS - One Time Password delivered via SMS transport channel.

A Policy Mechanism represents the composition of the user identity assertion which is governed by a set of rules, which comprise a Policy and are assigned to a user via a Group assignment. (e.g. user from group HelpDesk must use TOPT authentication)

Audit Log is the history of user actions kept in database for forensic and evidence in case of incident.

Biometric Service represent a connector which normalises interactions between Server Side Biometric services (Internal or External).

Internal Biometric Engines are the ones developed by Veridium or 3rd Party:

• 4F - Fingerprint touchless biometry
• vFace - Face biometry
• ....others ...

External Biometrics Engines are the one offered as a service:

• Azure Face API
• ....others....

External Validators represent connectors which normalise the interaction with external systems (usually token authenticators) which can be used through standard communication protocols. A good example is Gemalto token service which exposes the Radius protocol. VeridiumID can provide token validation against this service.

Enrolment procedure#

The purpose of Enrolment procedure is to associate an user identity from external repository with authentication methods offered by VeridiumID.

Internal Composition#

This is related to the process where the verification of a user identity is handled by VeridiumID. VeridiumID provides a mechanism to verify a user's password against a Directory Service and also add extra verification steps.

The trust for an identity within VeridiumID is created based on one or multiple verifications factors. For instance, a challenge to a user to authenticate with their current credentials, will result in a LDAP verification against an external Directory Service already present in the Enterprise infrastructure. At the same time, the VeridiumID connector to Directory Service, reads the user identity attributes like:

• Full Name
• Email Address
• Phone number
• Groups

In order to ensure an even stronger verification process, this initial step can be followed by additional steps. By sending an OTP over SMS to the user's phone number, we obtain a strong verification by composing what the user knows (the password) with what user has (the phone).

Fig. 2 - Enrolment composed by VeridiumID core

External Composition by direct communication#

This type of enrolment is based on a relation of trust between VeridiumID Server and an External Service which does the user verification and then reports back to VeridiumID.

The relation of trust between the External Service and VeridiumID is based on MTLS (Client Certificate authentication).

Fig. 3 - External Enrolment Service

External Composition by JWT#

The relation of trust between the External Service and VeridiumID is based on configuring a Public Key for the VeridiumID Server to verify the signature included in JWT Token.

Fig. 4 - External Enrolment Service by JWT

Authentication#

VeridiumID provides a mechanism to connect into a customer's infrastructure so that many of their applications can benefit from VeridiumID's strong authentication.

Since Enterprise space is dominated by Windows ecosystems (see bellow), VeridiumID offers a set of connectors to this ecosystem in order to protect the user login with strong authentication.

• Microsoft Active Directory
• Windows Desktops (Windows 7 and above)
• Windows Virtual Desktops
• Citrix Storefront (which delivers Virtual Desktops)
• Citrix NetScaler for internet access

Connectors offered by VeridiumID are:

• Windows Credential Provider
• SAML Identity Provider
• Radius

Each of the technologies above need to offer (where it is possible) the standard authentication methods defined in VeridiumID:

• QR Flow: where a QR code is displayed to the user
• Push: where a push notification is sent to an user phone(s)
• PIN where a former authentication token can be used (External Verification using Radius protocol communication)
• TOPT where a one time based code is obtained from the mobile application and entered on the desktop
• SMS where a code is sent by the server to the user's phone and entered on the desktop

The following section describes how each provider works.

Windows Credential Provider#

Enabling VeridiumID authentication on a Windows Desktop presents couple of challenges:

• Windows authentication is based on Kerberos protocol. It natively supports two type of authentications:
  • Password
  • Certificates (Smart Cards)
• The verification is performed on Domain Controller level.
• Authentication must be possible even when there is no direct communication between Desktop and Domain Controller. (Offline)

Veridium developed three components which provide all the required functionality:

• Windows Customer Credential Provider (installed on Desktop): which provides login screen and actual Kerberos login into Desktop.
• Enrolment Proxy which safely register Desktop into VeridiumID as a resource and enables direct communication with VeridiumID based on MTLS
• Registration Authority which is linked to Active Directory Private Key Infrastructure (PKI) and issues user certificates based on the VeridiumID authentication assertion.

The relation and communication is depicted in picture bellow:

Fig 5 - Windows Authentication components and communication

SAML Identity Provider#

Definition#

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML based markup language for security assertions (statements that service providers use to make access-control decisions). SAML is also:

• A set of XML-based protocol messages
• A set of protocol message bindings
• A set of profiles (utilising all of the above)

The single most important use case that SAML addresses is web-browser single sign-on (SSO). Single sign-on is relatively easy to accomplish within a security domain (using cookies, for example) but extending SSO across security domains is more difficult and has resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardised to promote interoperability. 

VeridiumID Implementation#

The policy within Veridium is to adopt open source implementations and add enterprise capabilities on top. Shibboleth (https://www.shibboleth.net/products/identity-provider/) is the most complete and popular open source implementation of SAML standard, and Veridium incorporates this into its service stack.

In picture bellow, there are components which make the links between Shibboleth, VeridiumID and Directory Service. Please remember that SAML is for authentication and authorization. That means, a SAML token will contain following attributes

• Authentication evidence
• Groups attributes (read from Directory Service)
• Other custom attributes

Fig 6 - VeridiumID - SAML - components

VeridiumID - Shibboleth Plugin#

Shibboleth overall architecture is the following:

Fig 7 - Shibboleth Overall architecture

For those who need to know more (in depth) about Shibboleth implementation please check the official documentation at https://wiki.shibboleth.net/confluence/display/IDP30/GeneralArchitecture

From functional point of view, it is important to know that the Shibboleth implementation allows you to defined new authentication flows, which can be used when defined as a new Service Provider.

In order to facilitate the authentication delegation to VeridiumID, we create Veridium authentication flows within Shibboleth as listed below.

• QR Flow
• Push Notification
• PIN Verification
• TOTP (to follow)
• SMS (to follow)
• FIDO 2 authentication (to follow)

RADIUS Support#

Definition#

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol, operating on port 1812 that provides centralised Authentication, Authorisation, and Accounting (AAA or Triple A) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc. in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.

VeridiumID Implementation#

Veridium incorporates the FreeRadius open source implementation into its service stack (https://freeradius.org/documentation/).

Fig 8 - VeridiumID - Radius components

Production use case - Citrix configuration#

Overview#

A typical Enterprise infrastructure contains the following components:

• Microsoft Active Directory (as a Directory Service)
• Windows Desktops
• Virtual Desktops
• Access to Virtual Desktops is done through Citrix infrastructure
  • StoreFront
  • NetScaler (gateway for internet access to Enterprise resources)

Fig. 9 - Veridium Citrix components communication