1. IBM Tivoli Access Manager (TAM)
and Two-Factor Authentication
2012
White paper

2. Business Requirement
Out-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 50
Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25
info@securit.biz • www.securit.biz
Belgium
Netherlands
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 TrustBuilder
SecurIT 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).

3. Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50
Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25
info@securit.biz • www.securit.biz
Belgium
Netherlands
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 Services
Besides 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.

4. Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50
Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25
info@securit.biz • www.securit.biz
Belgium
Netherlands
White paper
Selecting a two-factor
Authentication Service
This 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.
Conclusion
If 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 Authentication
As 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-

5. Franklin Rooseveltlaan 349d • 9000 Gent Phone: +32-9-265 02 70 • Fax: +32-9-265 02 50
Overschiestraat 184K • 1062 XK Amsterdam Phone: +31-20-408 44 27 • Fax: +31-20-408 44 25
info@securit.biz • www.securit.biz
Belgium
Netherlands
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 Packaging
TrustBuilder 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 Services
Optionally, 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).