OpenSSO One Time Password Authentication is the One That I Want

OpenSSO now contains a one time password authentication module. The one time password implementation can be configured as a two-factor authentication where the authentication process comprises something the user has as well as something the user knows. In other words, when the HMAC-based One Time Password (HOTP) authentication module is configured as part of an authentication chain with, for example, the LDAP authentication module, the user must authenticate using the configured LDAP directory as well as a one time password.

The HOTP authentication module works in tandem with one or more other authentication modules. Authentication to at least one of the other modules must be successful before attempting HOTP authentication as it requires the user identifier identified by a first authentication module. When the user attempts to log in to the OpenSSO console using an authentication chain configured with, for example, LDAP and HOTP, the LDAP authentication module login page is displayed. The user submits a valid LDAP user name and password - something the user knows. After successful authentication to the LDAP module, the HOTP authentication module login page is displayed.

The user clicks the Request OTP Code button to request that a one time password be sent to something the user has: a cell phone or an email account. The one time password will then be sent to the phone number or email address configured in the user's profile, retrieved by the user, entered in the OTP Code field on the login page, and submitted to OpenSSO. Assuming successful authentication, access to the protected resource is allowed.
NOTE: In order to communicate the one time password securely between parties, a hashed message authentication code (HMAC) is used to encode the data. When a one time password is requested, the HOTP authentication module stores the OTP in memory, appends an authentication tag to it that is computed as a function of the one-time password and the HMAC, and sends it to the user. When the user returns the one time password, the HOTP authentication module will compare the one received with the one it stores in memory and authentication succeeds only if the values match. The use of the HMAC algorithm is standardized in HOTP: An HMAC-Based One-Time Password Algorithm.
You can configure the user profile to receive the one time password via email or text message.

  • To receive a one time password via email, the Email Address attribute in the user's profile must be populated with a valid email address.
  • To receive the one time password via text message, the Telephone Number attribute in the user's profile must be populated with a ten digit mobile phone number. The phone number must be compatible with the Short Message Service (SMS), a standardized communication protocol that allows for the interchange of short text messages to mobile telephone devices. Additionally, the phone number must be appended with the provider's domain; for example, 14085551212@txt.att.net or 14085551212@messaging.sprintpcs.com. If the phone number is provided without a provider domain, the default domain txt.att.net will be appended to the phone number.

The OpenSSO administrator configures values for the following HOTP authentication module properties.

  • Authentication Level defines a value (set in reference to other enabled authentication modules) to indicate how much to trust HOTP authentications. For example, a human resources application might require level 5 authentication for access while the company directory only level 1. These values are used when defining policies for these resources to ensure the right level of authentication for higher trust resources. For more information on how the authentication level value works, see Authentication Level-based Authentication.
  • SMS Gateway Implementation Class defines a custom implementation of the public service provider interface (SPI) SMSGateway.java. The default implementation is com.sun.identity.authentication.modules.hotp.DefaultSMSGatewayImpl. This class sends the one time password to an email address or to a mobile device, depending on the configuration.
  • SMTP Host Name defines the machine and domain name of the outgoing mail server used to send the one time password to an email address. (SMTP is an acronym for Simple Mail Transfer Protocol, a standard used for email transmission.) There can only be one SMTP server per realm. OpenSSO supports mail servers that require user authentication in order to send email.
  • SMTP Host Port defines the port number of the outgoing mail server.
  • SMTP User Name defines the administrative user that will authenticate to the outgoing mail server for email transmission.
  • SMTP User password defines the password for the SMTP administrative user.
  • SMTP User password (confirm) confirms the password for the SMTP administrative user.
  • SMTP Connection defines whether the SMTP server uses the Secure Sockets Layer (SSL).
  • One Time Password Validity Length (in minutes) defines the amount of time for which the one time password will be valid. When the one time password code is generated, a creation time for it is recorded by the module. When the module receives the code back from the user, it checks the current time against the creation time to see if it has exceeded the maximum validity time.
  • One Time Password Length (in digits) defines whether the one time password is six or eight digits.
  • One Time Password Delivery defines whether the one time password is delivered via email or SMS text message to a cell phone. If email is selected, the user will receive an email with the one time password code if the user profile contains a valid email address. If SMS is selected, the user will receive the one time password code on a cell phone if the user profile contains a phone number. If both options are selected (the default value), the user will receive the one time password code through email and text. If the user profile does not contain the required email address or phone number, the HOTP authentication module will time out and user authentication will fail.

After configuration, the administrator creates an authentication chain using the HOTP authentication module with at least one other authentication module. (HOTP authentication can not be the first module in the authentication chain as it uses the user identifier garnered by the first module in the chain.) Following creation of the authentication chain, the administrator creates a policy for the appropriate resource using the authentication chain as the policy condition.

Test HOTP authentication using the following procedure.

  1. Create an authentication chain that contains the two authentication modules; for example, Data Store and HOTP.
  2. Add an email address or telephone number to the Demo user profile.
  3. Access the chain for authentication with the following URL: http://server:port/opensso/UI/Login?service=configured-auth-chain
    The Data Store authentication module page is displayed.
  4. Enter a user name and password.
    Use the default user demo and corresponding password changeit. Authentication is successful to the Data Store authentication module and the HOTP authentication module page is displayed.
  5. Click Request HOTP Code on the HOTP login page.
    The one time password will be sent to one or both: the email address and phone number.
  6. Enter the received HOTP code in the HOTP Code field and click Submit HOTP Code.
    Authentication is successful to the HOTP authentication module.

You can also:

  • Change the value of One Time Password Length and repeat the authentication steps to see the alternate code length.
  • Change the value of One Time Password Validity Length and repeat the authentication steps. For example, change the value to 1 (minute) and wait longer than one minute before submitting the code. HOTP authentication will fail.
  • Test authentication using the HOTP authentication module with a policy agent by defining a policy that uses the authentication chain to protect the resource.

The forceAuth=true parameter can be used to force user authentication for purposes of session upgrades. When this parameter is appended to the end of the authentication URL, the existing session token will be updated on successful authentication.

And now to the music: in 2004 the Beautiful South released Golddiggas, Headnodders and Pholk Songs, an album of covers. The first cut was the Olivia Newton-John/John Travolta hit from Grease, You're The One That I want. Here's a live version from the Jools Holland TV show. You've never heard it like this.

I miss the Beautiful South!

Comments:

Hi,

In my recent project we got a requirement to implement open SSO for two test applications. I have gone through many tutorials but I couldn't get information How to start? Can some one help me What are the steps to follow to implement Sun open SSO?

Thanks
Sudarsan.

Posted by Sudarsana on July 02, 2009 at 04:45 PM PDT #

Hi! Thank you for useful tips! I always helps me in my work with opensso.
May I ask one question?
I have 1 Sun App Server with two applications that i want to protect with opensso and 1 opensso agent. I decide to create 2 subreams in OpenSSO server for applications user data. Is there the way to use different login pages for my applications?
Thank you very much.
BR, Maria

Posted by Maria Radyuk on August 17, 2009 at 06:53 PM PDT #

Thanks for your comments, Maria. Glad you get use out of the entries. Check out this blog entry for info on your question:
http://blogs.sun.com/mrudul/entry/customize_authentication_ui_file_lookup. I am going to look at it myself and write more about it soon.

As for the first comment (which I must have missed) I would check out http://docs.sun.com/app/docs/coll/1767.1 including the Technical Overview and Deployment Examples for more information. Use the opensso alias if you have questions.

Posted by Michael Teger on August 20, 2009 at 04:30 AM PDT #

Hi,

For one of my customers I've been involved in an OpenSSO setup, which requires this functionality (for email only)

We've been able to set this up fine, but there is an issue that we've been running in to.
The email sessions for HOTP and Password reset seem to "clash"

If we use HOTP first, the password reset will fail due to the default mail session being taken.
If we use password reset first, then HOTP fails.

You seem like the go-to person for OpenSSO knowledge, can you point me in the right direction?

I'm using the latest release (express 8)

Regards,

Barry

Posted by Barry on December 14, 2009 at 05:47 PM PST #

Barry,

Please provide more information on your scenario. The HOTP authentication module instance can not identify the user being authenticated. What authentication module is being used to identify the user whose password is being reset?

Would you please send us the details of the authentication configuration (chain) you are using to invoke HOTP authentication?

Thanks,

Chares

Posted by Charles Wesley on December 14, 2009 at 11:10 PM PST #

Barry, you might be running into this issue:
https://opensso.dev.java.net/issues/show_bug.cgi?id=5853

Posted by DocTeger on December 15, 2009 at 02:13 AM PST #

Hi,

Yes, that is exactly it. (except it's on CentOS / Linux)
So the question is.. how do we proceed from here?

Regards,

Barry

Posted by Barry van Someren on December 15, 2009 at 02:21 AM PST #

Engineering has to investigate and fix the issue. This will happen after express 9 is released in early January.

Posted by DocTeger on December 15, 2009 at 02:36 AM PST #

Post a Comment:
Comments are closed for this entry.
About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today