Achieving OTP-based Authentication by Integrating Sun Java System Access Manager and ActivIdentity 4TRESS Authentication Server

Print-friendly Version

Great news for identity developers! An integration of Sun Java System Access Manager (henceforth, Access Manager) and ActivIdentity 4TRESS Authentication Server (henceforth, 4TRESS) is now in place. Newly available as an OpenSSO extension is an Access Manager authentication module that adopts the 4TRESS-supported one-time password (OTP) schemes, including Europay, MasterCard, and Visa (EMV or Chip and PIN). That Access Manager module is known as the 4TRESS OTP authentication module.

You can now do the following:

• Incorporate any OTP authentication schemes handled by 4TRESS into the Access Manager authentication framework.
  
  
• Protect your applications in an environment in which access control is managed by Access Manager with the OTP schemes supported by 4TRESS.

This article demonstrates a use case of the Sun-ActivIdentity integration, called session upgrade. With the Access Manager authentication service, you can upgrade a valid Single Sign-On (SSO) session through a second, successful authentication by the same user in the same Access Manager realm. Often, session upgrade becomes necessary when an enterprise's applications vary in their authentication requirements. A stronger authentication scheme such as OTP is advisable for applications that control ultrasensitive data.

Note: In the rest of this article, mentions of Access Manager refer to Access Manager or OpenSSO.

With 4TRESS, enterprises such as financial institutions and managed service providers can accomplish the following:

• Support numerous authentication methods, such as—
  
  
  • ActivIdentity or Open Authentication (OATH)-based OTP
  • EMV MasterCard's Chip Authentication Program (CAP) or Visa's Dynamic Passcode Authentication (DPA)
  • Memorable data and static passwords
  
  
• Foster customer confidence in online transactions.
  
  
• Enhance security and reduce costs.

Also, thanks to its highly scalable, secure, and centralized authentication capabilities, 4TRESS can manage many user credentials. Centralization means that 4TRESS enables a common set of user credentials for authentication across multiple access channels. For example, a bank customer can, with the same OTP, authenticate to the Internet banking service, which is protected by Access Manager, and to a phone banking system.

Through its core identity services, Access Manager simplifies the development of transparent SSO as a security component in networks. In addition, Access Manager enables authentication, authorization, federation, identity management, and sessions.

Figure 1 illustrates the deployment architecture for session upgrade.

Figure 1: Deployment Architecture for Session Upgrade

Here, the deployment of two different applications (resources) is on the same J2EE container, protected by an Access Manager J2EE Policy Agent 2.2 instance. The Policy Agent interfaces with Access Manager for session upgrade through the policy and authentication frameworks.

Here is the process flow:

1. The user authenticates on Access Manager to access Application1 at http://hostname:portnumber/application1 through Lightweight Directory Access Protocol (LDAP).
   
   A policy configured in Access Manager mandates LDAP authentication for Application1.
   
   
2. The user attempts to access Application2 at http://hostname:portnumber/application2 through the 4TRESS OTP authentication module.
   
   
3. The Policy Agent interfaces with Access Manager and verifies that the user session is still valid. Because an Application2 policy states that 4TRESS OTP authentication is a must for access, the Policy Agent redirects the user to Access Manager to log in with a 4TRESS OTP credential.
   
   
4. Upon successful authentication, Access Manager upgrades the user session by updating it with the properties relevant to the new authentication.
   
   
5. Access Manager allows the user to access Application2

To install and configure Access Manager and the 4TRESS OTP authentication module:

1. Install Access Manager on a supported application server or Web server, for example, Sun Java System Application Server or Sun Java System Web Server.
   
   
2. Install Access Manager J2EE Policy Agent 2.2 for the Access Manager deployment on a supported J2EE container. See the installation guides.
   
   
3. Install and configure the 4TRESS OTP authentication module in the Access Manager instance and name the instance 4TressOTP.

For the integration, the Access Manager module and supporting files reside under the OpenSSO extension directory. In the document directory is a how-to guide that describes how to install and configure the module to collaborate with a 4TRESS instance.

Next comes deployment:

1. Deploy two sample Web applications (Application1 and Application2) that are to be protected to the J2EE container that hosts the Policy Agent.
   
   
2. Configure the applications to work with the colocated Policy Agent.
   
   For details, see the postinstallation tasks in the Policy Agent installation guides.

In this deployment, the root realm, which contains all the configurations, such as the user entries, authentication modules, and policies, is called example.

Application1
Follow this procedure for Application1:

1. Create a set of users whose Access Manager IDs exactly match the corresponding user identifiers in 4TRESS.
   
   
   1. Log in to the Access Manager Administration Console, click the example realm, the Subject tab, and then the User subtab.
      
      
   2. Click New.
      
      A form is displayed.
      
      
   3. In the ID text field, type an Access Manager ID that corresponds to a user identifier in 4TRESS.
      
      For example, if the latter is CUST0001, type the same string.
      
      
   4. Type the password for the LDAP authentication.
      
      For the integration to work, the user identifiers in both the 4TRESS and Access Manager user profiles must match.
      
      
   5. Repeat steps 1a through 1d for the remaining users.
   
   
2. Create a module instance of the LDAP authentication scheme in the realm.
   
   By default, a module called LDAP resides in the root realm. If that module is absent, do the following:
   
   
   1. Log in to the Access Manager Administration Console, click the example realm and the Authentication tab, and then scroll down to the subsection Module Instance. Click New.
      
      
   2. Type LDAP in the Name text field and specify LDAP as the type.
      
      You are returned to the Authentication main page.
      
      
   3. Click the newly created LDAP module link and configure the module instance with the LDAP server details.
   
   
3. Create an Access Manager policy to mandate LDAP authentication:
   
   
   1. In the Administration Console, click the example realm and the Policies tab.
      
      
   2. Click the New Policy button.
      
      
   3. Type the policy name, for example, Application1Policy.
      
      
   4. Go to the Rules section and click New.
      
      
   5. Specify a service type for the rule. Click Next.
      
      Since Application1 is a Web application, the service type is URL Policy Agent.
      
      
   6. Type a rule name (for example, Application1) and the resource name, which is the URL for the main page of Application1 (for example, http://hostname:portnumber/application1/*).
      
      
   7. Specify the actions for the resource. In this case, specify Allow for both GET and POST. Click Finish.
   
   
4. Create the policy subjects.
   
   
   1. Click New in the Subjects section.
      
      
   2. Select the Access Manager identity subject type.
      
      
   3. Type a reference name for those subjects, for example, 4TressUsers, and filter for the users created in step 1. Click Finish.
      
      If many users are in the set, configure a group for them.
      
      
   4. Repeat steps 4a through 4c for the remaining subjects.
   
   
5. Specify in the policy's condition a mandate for user authentication with LDAP for access to Application1.
   
   
   1. In the Condition section, click New and specify Authentication Module Instance as the condition type.
      
      
   2. Type the condition name, for example, LDAPCondition, and click Add.
      
      The available module instances are listed.
      
      
   3. Select the LDAP instance and click Finish.
      
      Figure 2 shows the Policy page that is displayed.
      
      

      Figure 2: Policy Page

       
      
   4. Click Save.

Application2
Next, create an Access Manager policy for Application2, which requires 4TRESS OTP authentication:

1. In the Access Manager Administration Console, click the example realm link, the Policies tab, and the New Policy button.
   
   
2. Type the name for the policy, for example, Application2Policy.
   
   
3. Go to the Rules section and click the New button.
   
   
4. Specify a service type for the rule: Since Application2 is a Web application, specify URL Policy Agent. Click Next.
   
   
5. Type a rule name (for example, Application2) and the resource name, which is the URL for the main page of Application2 (for example, http://hostname:portnumber/application2/*).
   
   
6. Specify the actions for the resource. In this case, specify Allow for both GET and POST. Click Finish.
   
   
7. Create the policy subjects:
   
   
   1. Click New in the Subjects section.
      
      
   2. Select the Access Manager identity subject type.
      
      
   3. Type a reference name for the subjects, for example, 4TressUsers, and filter for the users created in step 1. Click Finish.
      
      If many users are in the set, configure a group for them.

Finally, specify in the policy's condition a mandate for user authentication with 4TRESS OTP for access to Application2:

1. In the Condition section, click New and specify Authentication Module Instance as the condition type.
   
   
2. Type the condition name, for example, 4TRESSCondition, and click Add.
   
   The available module instances are listed.
   
   
3. Select the 4TRESSOTP instance and click Finish.
   
   
4. Click Save.
   
   
The Application2 policy looks like Figure 3.



Figure 3: Application2 Policy

 

To test the integration, go to the login page for the OpenSSO Web console in a browser and then do the following:

1. Go to Application1.
   
   You are redirected to Access Manager to log in with LDAP.
   
   
2. Type the LDAP user name and password that were configured for CUST0001.
   
   The main page of Application1 is displayed.
   
   
3. Go to Application2.
   
   You are directed to the login page for the 4TRESS OTP authentication module. See Figure 4.
   
   

   Figure 4: Login Page for the 4TRESS OTP Authentication Module

    
   
4. Type the credentials for the module: the user identifier (for example, CUST0001) and an OTP.
   
   To retrieve sample OTPs, see the 4TRESS OTP extension page on OpenSSO.
   
   The main page of Application2 is displayed.

Special thanks to Julian Lovelock, director of product management at ActivIdentity, for his excellent comments.

• Sun Java System Access Manager
  
  • Main page
  • Developer home
  • Software Forum
  
  
• Open Web SSO Project (OpenSSO)
  
  
• ActivIdentity 4TRESS Authentication Server
  
  
• Sun developer services
  • Support
  • Training and certification