IBM Tivoli Access Manager (TAM) and Two-Factor Authentication

2012

White paper

Business RequirementOut-of-the-box TAM only supports two-factor authen-tication using RSA SecurID. Apart from requiring the installation of an extra component (the RSA Authen-tication Manager) this feature is also limited to the authentication selection policy of TAM. The authenti-cation selection policy dictates the way a user will be prompted for authentication in an environment that supports multiple authentication mechanisms next to each other; e.g. both username/password and two-factor authentication. In the context of TAM, that po-licy is restricted to the authentication level associated with the selected resource. Authentication policies that include specific user communities (e.g. internal versus external users) or that deal with migration between au-thentication mechanisms (e.g. migrate from username/password to two-factor authentication) cannot be pro-vided by a standard TAM installation.

Fortunately TAM provides two interfaces to extend its authentication mechanisms:• C-Authentication API interface (former CDAS)• External Authentication Interface (aka EAI)

The first solution relies on an authentication module that gets plugged into WebSEAL and which is con-figured to deal with additional authentication mech-anisms. The limitation of this interface is that it can only be activated using the standard authentication policies of TAM. Hence, the examples shown above, that deal with different user communities and migra-tion scenarios, cannot be supported by this interface in an efficient way.

Complex authentication policies require extensive in-

Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25 info@securit.biz • www.securit.biz

BelgiumNetherlands

1 White paper

teraction with the user. This is best illustrated by some examples:• user is prompted to select the authentication

mechanism that provides sufficient strength to access the requested resource (e.g. username/password for account balance and two-factor for money transfers)

• user is prompted to select the authentication mechanism for which he is enrolled (e.g. two-factor authentication requires the user to be in possession of a hardware, software or mobile token)

• user is asked to enrol for a new authentication mechanism (e.g. user received a two-factor au-thentication token and is requested to activate it)

Such scenarios can only be achieved using the EAI in-terface of TAM. Using EAI, TAM points to a backend service (usually called the EAI Server) that will interact with the user to enforce the authentication policy, like selecting an appropriate authentication mechanism or enrolling for a stronger (two-factor) one.

SecurIT TrustBuilder is such an EAI server.

SecurIT TrustBuilderSecurIT TrustBuilder is an off-the-shelf EAI compliant Authentication Server. It is however quite distinct from other authentication servers on the market in the sense that it provides, besides a wide variety of authentica-tion mechanisms, also the functionality of an authen-tication policy broker. The authentication policy broker is controlled by a workflow engine that can be config-ured using a web-based GUI (see example below).

Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25 info@securit.biz • www.securit.biz

BelgiumNetherlands

White paper

This unique feature of TrustBuilder allows it to be tai-lored to the ever changing challenge of IAM (Identity and Access Management) in e-business environments. Such an environment consists mainly of three key ac-tors:• a user community• a set of exposed services• authentication technology

Each organization is constantly trying to increase prof-its or reduce costs by improving the way it deals with its internal and external business. This can be achieved by growing the user community, extending the exposed services and improving authentication technology.

Hence an authentication solution should not be a static component that deals with today’s requirements, but should be a platform that can grow with, and adapt to new challenges. SecurIT TrustBuilder was designed from scratch to operate in such environments. It was conceived and matured in environments that put a high pressure on performance, availability and security.

As such, it should be no surprise that SecurIT Trust-Builder today sits at the core of IAM solutions from several financial institutions around the world.

Some key players in the market that use TrustBuilder (see figure).

TrustBuilder Authentication ServicesBesides being an authentication broker, TrustBuilder also provides out-of-the-box a wide variety of authen-tication services. These services fall into two categories:• Embedded Authentication Services• Third Party Authentication Services

Embedded Authentication Services are fully provided by TrustBuilder and do not require any external com-ponents, software or licenses. I.e. they can be enabled using TrustBuilder only.

Third Party Authentication Services rely on external technology that has been integrated with TrustBuilder. In some cases they also require additional third party

2

licenses and hardware or software components.

Embedded Authentication Services• Username/password• Smartcards and Certificates (X.509)• Two-factor authentication using TrustBuilder

OATH• Federated authentication using SAML• Federated authentication using OAuth

Third Party Authentication Services• Two-factor authentication using Vasco DigiPass• Two-factor authentication using Google Authen-

ticator• Two-factor authentication using Gemalto SAS• Two-factor authentication using RSA SecurID• Two-factor authentication using Kobil SecOVID• Voice recognition from SentryCom• Fingerprint recognition from CH Biometrics

The choice of authentication services is influenced by several factors.

Embedded two-factor Authentication Services are part of the TrustBuilder license and hence are more cost effective. As they are embedded, they also come with pre-defined selection, enrolment and activation poli-cies. On the other side, they provide less options than specialized solutions. Third Party two-factor Authen-tication Services require additional licenses but often provide a wider range of authentication devices.

The advantage of TrustBuilder is that there is no need for the customer to decide up front which authentica-tion services will be implemented. Furthermore, there is no buy-in into any vendor of authentication solutions. Different authentication services, embedded and third party, can happily live next to each other and can even rely on each other’s services. E.g. it would be possible to start with Google Authenticator and use this service at a later stage to enrol users (or a specific user com-munity) into Vasco DigiPass two-factor authentication.

Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25 info@securit.biz • www.securit.biz

BelgiumNetherlands

White paper

Selecting a two-factor Authentication ServiceThis paragraph compares a selection of key two-factor solutions that TrustBuilder provides out-of-the-box. It should help customer selecting the most appropriate authentication solution for their environment.

The solutions will be compared according to the fol-lowing categories:

Extra Licenses Required This category indicates whether any additional licenses are required next to the TrustBuilder licenses.

Supported Token Types Which types of tokens are supported by this solution. There are basically four types of tokens:• Hardware token: little devices that users carry

along• Software token: active plug-ins in browsers (e.g.

applet, ActiveX)• Mobile token: mobile application for Smartphone• SMS token: SMS sent to mobile phone

Signing Functionality Indicates whether the solution can also be used to sign application transactions (e.g. money transfer)

3

TAM Integration Indicates how the authentication service can be inte-grated with TAM to provide SSO.

There are basically two options:• Direct: Direct integration in TrustBuilder• OAuth: Using federated OAuth SSO

Enrolment Services Are services provided out-of-the-box to automatically enrol users for two-factor authentication. Note that even when they are not available out-of-the-box, en-rolment services can still be configured on TrustBuilder.

ConclusionIf a customer does not want to manage its own users, a cloud-based authentication mechanism like Google Authenticator might be the best approach. This re-quires however federation based SSO for integration within local applications. This service can also be pro-vided by TrustBuilder. If token flexibility is a must, a specialized two-factor vendor like Vasco could be a better option. If scale and budget matters, TrustBuilder OATH is probably the preferred approach.

TrustBuilder OATH two-factor AuthenticationAs TrustBuilder OATH two-factor Authentication is an out-of-the-box solution provided by SecurIT as part of TrustBuilder, it is described in some more detail below.

The solution is based on the specification of the OATH consortium. It implements the TOTP (Time-based One Time Password) specifi-cation described in In-ternet RFC 6238.

The figure on the right illustrates the overall architecture of the solu-tion and shows how it integrates with TAM.

TrustBuilder sits as an EAI server behind Web-SEAL. It is responsible for the communication with the user.

It is based on Connector technology to tie into backend services like LDAP servers, Databases, Web Services but also APIs that are provided by authentication solutions (e.g. Vasco DigiPass Vacman Controller, OATH API). In this scenario three Connectors are used:

LDAP Connector This Connector is used to register secret keys for us-

Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25 info@securit.biz • www.securit.biz

BelgiumNetherlands

White paper

ers and to flag the user for two-factor authentication (after enrolment).

OATH Connector The OATH Connector basically implements all func-tions of the TOTP specification. It deals e.g. with the generation and validation of OTPs.

HTTP/SOAP Connector This Connector is used to hook up to an SMS service to send OTPs to mobile users (in case no mobile applica-tion would be available).

TrustBuilder implements three services:Two-factor enrolment This service will allow a user to enrol for two-factor au-thentication. The service can be enable as a protected TAM service and hence the user can e.g. access it using his existing TAM credential (e.g. username/password). As this reveals the user to the TrustBuilder enrolment workflow, it can on-the-fly register a secret key (for OTP generation) and a GSM number (to send the OTP to the user by SMS).

As illustrated by the next figure, at the end of the en-rolment process the user is shown a QR code. This QR code can be scanned using the mobile application to automatically register the secret key that is used as the basis for OTP generation. This page can of course be customised. The example also shows the secret key on top of the page. This would allow to manually enter the code in case no QR scanner or camera would be available on the Smartphone.

OTP generation This workflow will only be used when a user decided to authenticate using an SMS based OTP. The OTP gets randomly generated based on the established secret key and is sent to the user’s previously registered GSM number.

In case the user would authenticate using a mobile device, this workflow should not be accessed by the user as the OTP is generated by the mobile application. The figure below shows a screendump of the application on iPhone. In this case we used the sample Google Authenticator application as this is also OATH compliant. The figure shows two virtual OTP generators, the first one for Google Applica-tions, the second one for Trust-

4

Builder. OATH compliant mobile application exist also for Android and Windows Mobile.

OTP validation Whether the OTP was generated by the mobile appli-cation or sent to the user using an SMS, the user will provide this OTP to the OTP validation service as part of the authentication process. Upon successful valida-tion of this OTP by TrustBuilder, it will return an EAI response, hence signing the user on to WebSEAL.

TrustBuilder PackagingTrustBuilder comes in two flavours:• As a J2EE application that can be hosted on a

shared WebSphere environment• As a software appliance with embedded Web-

Sphere application server

From a functional point of view, both solutions are identical. The most appropriate choice depends on the customer’s preference.

As described above, TrustBuilder can be used for a va-riety of authentication mechanisms. However, in case the customer wants to use TrustBuilder for two-factor authentication, all existing basic workflows (related to the selected solution) will also be provided. For Trust-Builder OATH this even means the customer can roll the solution out as a demonstration service in less than a day.

TrustBuilder ServicesOptionally, as part of the TrustBuilder Package, the customer can also acquire a basic set of services that will deal with the implementation of two-factor based authentication using any of the above-mentioned sup-ported technologies.

This package consist of the following services:• Gathering and documenting of the authentica-

tion requirements of the customer - 2 days• Architecture & Design of the solution, including

technical configuration documentation - 5 days• Operational system including maximum 2 Trust-

Builder instances (it is assumed that the customer provides a working TAM environment) - 5 days

• Cookbook for the deployment of the solution in an Acceptance or Production environment - 3 days

• Standard TrustBuilder training - 3 days• Solution training for administrators - 2 days

Note that the customer is responsible for making sure that any external components have been acquired and are installed, configured and operational.

This package consists of 20 days of consultancy. The maximum number of days spent on each task is shown above. Of course the customer is free to order extra days in case there would be additional requirements (e.g. implementation of non-standard workflows).