« Previous month (May 2009) | Main | Next month (Jul 2009) »
Tuesday Jun 30, 2009

OpenSSO Resource Authentication Is Not The Gateway Servlet

In previous versions of OpenSSO, the Gateway Servlet was used to authenticate against an authentication module configured to protect a specific resource. This resource authentication type though was developed using the Policy Service framework and contains limitations. With the iminent release of OpenSSO Express Build 8, resource authentication becomes available as part of the Authentication Service framework - without calling the Gateway Servlet (which will be deprecated in a future release).

Resource authentication is based on the client environment parameters defined in the HTTP header of the request. After receiving a request for access, the Authentication Service passes the resource name and appropriate environment parameters to the Policy Service to determine the authentication type to be used. (Resource authentication is parallel to the other authentication types but, because the authentication process is based on environment variables, resource authentication will ultimately run one of the other configured authentication types rather than having a fixed authentication process itself.) The Policy Service returns an advice message to indicate the appropriate authentication type to call. The user is then prompted for the appropriate credentials for the authentication type and, if successful, continues the process with session validation as documented in the Sun OpenSSO Enterprise 8.0 Technical Overview. The process flow diagram illustrates this.

To use resource authentication, you need to create a policy with a condition that defines the authentication process for the protected resource, and to define a login URL to call the authentication process based on the resource. If there is no policy defined for the protected resource, the user will be prompted from the default authentication process defined for the realm.

In the following formats for the IF/THEN condition, Environment_Name is a URL query parameter or an HTTP header attribute, Authentication_Type is one of the OpenSSO authentication types (module, user, role, service or authlevel), and Authentication_Process is a configured authentication process (either an instantiated authentication module or authentication chain).

  • IF Environment_Name=value THEN Authentication_Type=[realm:]Authentication_Process
    This means if the IF condition is satisfied, the user will attempt authentication using the authentication process defined by THEN.

  • IF Environment_Name=value THEN realm=realm_name
    This means if the IF condition is satisfied, the user will attempt authentication using the authentication process defined for the specified realm.

  • IF Environment_Name=value THEN redirectURL=redirect_URL
    This means if the IF condition is satisfied, the user will be redirected to the URL specified as a value for redirectURL parameter.

More information will be forthcomingwhen Express Build 8 is released. Check the OpenSSO Resource Center for any new documentation.

And in tribute to the musical genius that was Michael Jackson, here is his masterful performance of Billie Jean on Motown 25 when a little moonwalk blasted him into the stratosphere.

Posted at 10:46AM Jun 30, 2009 by Michael Teger in Sun  |  Comments[0]

Thursday Jun 18, 2009

Moving OpenSSO Session Cookie Hijacking Information

In reorganizing and rewriting the OpenSSO Enterprise 8.0 Administration Guide, I thought the chapter on session cookie hijacking was in the wrong place. The Administration Guide is a guide for administering and configuring OpenSSO Enterprise using the console and the command line. The information in the session cookie hijacking chapter, with its emphasis on a technical overview, security issues and configuration seemed more inline with a task that would be done post OpenSSO installation and deployment. Thus the chapter was moved, intact, to the OpenSSO Enterprise 8.0 Installation and Configuration Guide.

So, if looking for information on session cookie hijacking, check out Chapter 19, Taking Precautions Against Session-Cookie Hijacking in an OpenSSO Enterprise Deployment in the aforementioned ICG.

And speaking of moving, here's Kate Bush, live at the Hammersmith Odeon, with the first cut from The Kick Inside, Moving.

Move over, Madonna. THIS was the first time I had seen anyone use the telephone operator microphone in a live performance.

Posted at 09:52AM Jun 18, 2009 by Michael Teger in Sun  |  Comments[0]

Monday Jun 15, 2009

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!

Posted at 01:58PM Jun 15, 2009 by Michael Teger in Sun  |  Comments[3]