O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
IBM Tivoli Access Manager (TAM)and Two-Factor Authentication2012White paper
Business RequirementOut-of-the-box TAM only supports two-factor authen-tication using RSA SecurID. Apart from requiring theinstallation of an extra component (the RSA Authen-tication Manager) this feature is also limited to theauthentication selection policy of TAM. The authenti-cation selection policy dictates the way a user will beprompted for authentication in an environment thatsupports multiple authentication mechanisms next toeach other; e.g. both username/password and two-factor authentication. In the context of TAM, that po-licy is restricted to the authentication level associatedwith the selected resource. Authentication policies thatinclude specific user communities (e.g. internal versusexternal 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 itsauthentication mechanisms:• C-Authentication API interface (former CDAS)• External Authentication Interface (aka EAI)The first solution relies on an authentication modulethat gets plugged into WebSEAL and which is con-figured to deal with additional authentication mech-anisms. The limitation of this interface is that it canonly be activated using the standard authenticationpolicies of TAM. Hence, the examples shown above,that deal with different user communities and migra-tion scenarios, cannot be supported by this interface inan 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 firstname.lastname@example.org • www.securit.bizBelgiumNetherlands1 White paperteraction with the user. This is best illustrated by someexamples:• user is prompted to select the authenticationmechanism that provides sufficient strength toaccess the requested resource (e.g. username/password for account balance and two-factor formoney transfers)• user is prompted to select the authenticationmechanism for which he is enrolled (e.g. two-factor authentication requires the user to be inpossession of a hardware, software or mobiletoken)• user is asked to enrol for a new authenticationmechanism (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 backendservice (usually called the EAI Server) that will interactwith the user to enforce the authentication policy, likeselecting an appropriate authentication mechanism orenrolling for a stronger (two-factor) one.SecurIT TrustBuilder is such an EAI server.SecurIT TrustBuilderSecurIT TrustBuilder is an off-the-shelf EAI compliantAuthentication Server. It is however quite distinct fromother authentication servers on the market in the sensethat it provides, besides a wide variety of authentica-tion mechanisms, also the functionality of an authen-tication policy broker. The authentication policy brokeris 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 email@example.com • www.securit.bizBelgiumNetherlandsWhite paperThis unique feature of TrustBuilder allows it to be tai-lored to the ever changing challenge of IAM (Identityand 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 technologyEach organization is constantly trying to increase prof-its or reduce costs by improving the way it deals with itsinternal and external business. This can be achieved bygrowing the user community, extending the exposedservices and improving authentication technology.Hence an authentication solution should not be a staticcomponent that deals with today’s requirements, butshould be a platform that can grow with, and adaptto new challenges. SecurIT TrustBuilder was designedfrom scratch to operate in such environments. It wasconceived and matured in environments that put ahigh 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 fromseveral financial institutions around the world.Some key players in the market that use TrustBuilder(see figure).TrustBuilder Authentication ServicesBesides being an authentication broker, TrustBuilderalso provides out-of-the-box a wide variety of authen-tication services. These services fall into two categories:• Embedded Authentication Services• Third Party Authentication ServicesEmbedded Authentication Services are fully providedby TrustBuilder and do not require any external com-ponents, software or licenses. I.e. they can be enabledusing TrustBuilder only.Third Party Authentication Services rely on externaltechnology that has been integrated with TrustBuilder.In some cases they also require additional third party2licenses and hardware or software components.Embedded Authentication Services• Username/password• Smartcards and Certificates (X.509)• Two-factor authentication using TrustBuilderOATH• Federated authentication using SAML• Federated authentication using OAuthThird 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 BiometricsThe choice of authentication services is influenced byseveral factors.Embedded two-factor Authentication Services are partof the TrustBuilder license and hence are more costeffective. As they are embedded, they also come withpre-defined selection, enrolment and activation poli-cies. On the other side, they provide less options thanspecialized solutions. Third Party two-factor Authen-tication Services require additional licenses but oftenprovide a wider range of authentication devices.The advantage of TrustBuilder is that there is no needfor the customer to decide up front which authentica-tion services will be implemented. Furthermore, there isno buy-in into any vendor of authentication solutions.Different authentication services, embedded and thirdparty, can happily live next to each other and can evenrely on each other’s services. E.g. it would be possibleto start with Google Authenticator and use this serviceat 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 firstname.lastname@example.org • www.securit.bizBelgiumNetherlandsWhite paperSelecting a two-factorAuthentication ServiceThis paragraph compares a selection of key two-factorsolutions that TrustBuilder provides out-of-the-box. Itshould help customer selecting the most appropriateauthentication solution for their environment.The solutions will be compared according to the fol-lowing categories:Extra Licenses Required This category indicates whether any additional licensesare 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 carryalong• Software token: active plug-ins in browsers (e.g.applet, ActiveX)• Mobile token: mobile application for Smartphone• SMS token: SMS sent to mobile phoneSigning Functionality Indicates whether the solution can also be used to signapplication transactions (e.g. money transfer)3TAM 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 SSOEnrolment Services Are services provided out-of-the-box to automaticallyenrol users for two-factor authentication. Note thateven when they are not available out-of-the-box, en-rolment services can still be configuredon TrustBuilder.ConclusionIf a customer does not want to manage its own users,a cloud-based authentication mechanism like GoogleAuthenticator might be the best approach. This re-quires however federation based SSO for integrationwithin local applications. This service can also be pro-vided by TrustBuilder. If token flexibility is a must, aspecialized two-factor vendor like Vasco could be abetter option. If scale and budget matters, TrustBuilderOATH is probably the preferred approach.TrustBuilder OATH two-factor AuthenticationAs TrustBuilder OATH two-factor Authentication is anout-of-the-box solution provided by SecurIT as part ofTrustBuilder, it is described in some more detail below.The solution is based on the specification of the OATHconsortium. It implements the TOTP (Time-based OneTime Password) specifi-cation described in In-ternet RFC 6238.The figure on the rightillustrates the overallarchitecture of the solu-tion and shows how itintegrates with TAM.TrustBuilder sits as anEAI server behind Web-SEAL. It is responsiblefor the communicationwith the user.It is based on Connector technology to tie into backendservices like LDAP servers, Databases, Web Services butalso APIs that are provided by authentication solutions(e.g. Vasco DigiPass Vacman Controller, OATH API). Inthis 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 email@example.com • www.securit.bizBelgiumNetherlandsWhite paperers 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 thegeneration and validation of OTPs.HTTP/SOAP Connector This Connector is used to hook up to an SMS service tosend 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 protectedTAM service and hence the user can e.g. access it usinghis existing TAM credential (e.g. username/password).As this reveals the user to the TrustBuilder enrolmentworkflow, it can on-the-fly register a secret key (forOTP generation) and a GSM number (to send the OTPto 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 QRcode can be scanned using the mobile application toautomatically register the secret key that is used as thebasis for OTP generation. This page can of course becustomised. The example also shows the secret key ontop of the page. This would allow to manually enterthe code in case no QR scanner or camera would beavailable on the Smartphone.OTP generation This workflow will only be used when a user decidedto authenticate using an SMS based OTP. The OTP getsrandomly generated based on the established secretkey and is sent to the user’s previously registered GSMnumber.In case the user would authenticate using a mobiledevice, this workflow should not be accessed by theuser as the OTP is generated bythe mobile application. The figurebelow shows a screendump ofthe application on iPhone. In thiscase we used the sample GoogleAuthenticator application as this isalso OATH compliant. The figureshows two virtual OTP generators,the first one for Google Applica-tions, the second one for Trust-4Builder. OATH compliant mobile application exist alsofor 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 willprovide this OTP to the OTP validation service as partof the authentication process. Upon successful valida-tion of this OTP by TrustBuilder, it will return an EAIresponse, hence signing the user on to WebSEAL.TrustBuilder PackagingTrustBuilder comes in two flavours:• As a J2EE application that can be hosted on ashared WebSphere environment• As a software appliance with embedded Web-Sphere application serverFrom a functional point of view, both solutions areidentical. The most appropriate choice depends on thecustomer’s preference.As described above, TrustBuilder can be used for a va-riety of authentication mechanisms. However, in casethe customer wants to use TrustBuilder for two-factorauthentication, all existing basic workflows (related tothe selected solution) will also be provided. For Trust-Builder OATH this even means the customer can rollthe solution out as a demonstration service in less thana day.TrustBuilder ServicesOptionally, as part of the TrustBuilder Package, thecustomer can also acquire a basic set of services thatwill deal with the implementation of two-factor basedauthentication 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, includingtechnical configuration documentation - 5 days• Operational system including maximum 2 Trust-Builder instances (it is assumed that the customerprovides a working TAM environment) - 5 days• Cookbook for the deployment of the solutionin an Acceptance or Production environment - 3days• Standard TrustBuilder training - 3 days• Solution training for administrators - 2 daysNote that the customer is responsible for making surethat any external components have been acquired andare installed, configured and operational.This package consists of 20 days of consultancy. Themaximum number of days spent on each task is shownabove. Of course the customer is free to order extradays in case there would be additional requirements(e.g. implementation of non-standard workflows).