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, or If the phone number is provided without a provider domain, the default domain 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) 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!

Friday May 08, 2009

An ASP.NET OpenSSO Fedlet? Sign of the Times

In light of the OpenSSO Fedlet's recent award for innovation, here are instructions to configure and test the new ASP.NET Fedlet.

The Fedlet is a small archive that can be embedded into a service provider's web application to allow for SAMLv2 single sign-on between an identity provider instance of OpenSSO and the service provider application - WITHOUT installing OpenSSO on the service provider side. With the upcoming release of OpenSSO Enterprise 8.0 Update 1, the Fedlet technology has been extended to the ASP.NET platform. The code is currently available in the nightly builds.

OpenSSO Enterprise 8.0 Update 1 includes the Fedlet.dll, template metadata files, and a sample ASP.NET application for testing the communications. The Fedlet.dll initiates single sign-on with an identity provider and enables the receipt of an authentication response by the service provider using an HTTP-POST binding.

To configure the Sample Application for communications with the ASP.NET Fedlet, follow these first three procedures. The final procedure has the ASP.NET code to use in an existing application.

To Configure the Identity Provider

  1. Create the hosted identity provider using the Common Tasks work flow in the OpenSSO Enterprise console.

    You will need the name of the circle of trust in To Configure the Service Provider and the ASP.NET Fedlet.
  2. Export the identity provider's standard metadata file.

    idp.xml can be exported by accessing the export metadata page at http://idp-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp
  3. Register the remote service provider using the modified standard metadata file sp.xml and the Register Remote Service Provider work flow in the OpenSSO Enterprise console.

    This standard metadata is modified in To Configure the Service Provider and the ASP.NET Fedlet thus, registering the service provider on the identity provider machine is the last step of that procedure.

To Configure the Service Provider and the ASP.NET Fedlet

  1. Download the OpenSSO Enterprise ZIP archive to the service provider machine and unzip it.
  2. Unzip the in the /opensso/fedlet/ folder.
  3. Move the /opensso/fedlet/ folder to a temporary directory.
  4. Change to the /tmp/ directory.
  5. Make copies of the template files.
    • Copy sp.xml-template to sp.xml.
    • Copy sp-extended.xml-template to sp-extended.xml.
    • Copy idp-extended.xml-template to idp-extended.xml.
    • Copy fedlet.cot-template to fedlet.cot.

  6. Swap out the following tags in the copied metadata files.

    • Replace FEDLET_COT with the name of the circle of trust of which the remote identity provider and the local service provider are members.
    • Replace FEDLET_ENTITY_ID with a unique identifier used to locate the Fedlet. This value is analogous to the service provider EntityID. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider when looking in the OpenSSO console is the value of the EntityID.
    • Replace FEDLET_URL with the URL of the Fedlet; for example, http://sp-machine.domain/SampleApp/fedletapplication.aspx.
    • Replace IDP_ENTITY_ID with the entity ID of the remote identity provider. The EntityID attribute is under the EntityDescriptor element that is passed to the service provider as part of the XML exchange. The Name attribute of a configured entity provider in the OpenSSO console is the value of the EntityID.
  7. Return to the identity provider machine to register the service provider using the modified sp.xml file and making sure to associate the service provider and the identity provider with the same circle of trust.

To Configure the Sample Application and Test the ASP.NET Fedlet

The Sample Application should be deployed using ASP.NET version 3.5 and Microsoft Internet Information Server versions 6 or 7.

  1. Navigate to the /tmp/ folder on the service provider machine.
  2. Copy the modified metadata files idp-extended.xml, sp.xml, sp-extended.xml, and fedlet.cot) to /tmp/
  3. Copy the remote identity provider's standard metadata file to the service provider machine.

    Be sure the file is named idp.xml.
  4. Place idp.xml in /tmp/
  5. Confirm that the Fedlet.dll is in the Sample Application's /tmp/ folder.
  6. Within Internet Information Server (IIS), create a virtual directory using the /tmp/ directory.

    • IIS 6 (Windows 2003) has Add Virtual Directory. Be sure to have Read and Script permissions set for the application.
    • IIS 7 (Windows 2008 and Vista) has Add Application with no additional options required to be set.
  7. Open the Sample Application in your browser using the URL, http://sp-machine.domain/SampleApp
  8. Click the IDP Initiated SSO link to perform identity provider-initiated single sign-on.
  9. Enter the appropriate user credentials.

    The OpenSSO user demo with a password of changeit will work. After a successful authentication, the fedletapplication.aspx page is displayed with access to the AuthnResponse information.

To Integrate the ASP.NET Fedlet with an Existing Application

The Sample Application demonstrates how to retrieve attributes and subject information from the SAMLv2 assertion in an AuthnResponse object. The following code can be integrated in custom applications to do the same. It is expected to be placed in an aspx page or ASP.NET URI to receive the authentication response in an HTTP-POST binding.

       AuthnResponse authnResponse = null; 
           ServiceProviderUtility spu = new ServiceProviderUtility(Context); 
           authnResponse = spu.GetAuthnResponse(Request); 
       catch (Saml2Exception se) 
           // invalid AuthnResponse received 
       catch (ServiceProviderUtilityException spue) 
           // issues with deployment (reading metadata) 

More information on the Fedlet is in The Fedlet Cyrkle of Information.

And now for another Sign of the Times with the Belle Stars.

Tuesday May 05, 2009

WIKI COMMUNITY REVIEW: Managing OpenSSO Authentication

Feel free to click on over to the OpenSSO Resource Center wiki and review the articles listed on the Managing Authentication page. This is the first chapter to be ported from the Administration Guide on The material has been rewritten to include more information and to remove information that is no longer relevant.

Leave your comments here or as comments on the Resource Center page.

But if you're not on the wiki you should the great Kirsty MacColl. Here's her video, He's On The Beach. Pop perfection!

Friday May 01, 2009

Romanticizing the OpenSSO WSSAuth Authentication Module

The WS-Security specifies the Username Token Profile for providing basic authentication information. The profile describes how the UsernameToken element can be used as a means for communicating a user identifier and password between a web service provider (WSP) and web service client (WSC). The OpenSSO WSSAuth authentication module validates the credentials presented by the WSC using the UsernameToken profile.

The UsernameToken profile contains an element to present a hash of the user's password - the PasswordDigest element. Using this element adds security as the password is not exposed as clear text. The following steps show how to configure for authentication using the Username Token profile with a one way hash password.
  1. Login into the OpenSSO console as administrator.
  2. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Client -> wsc
  3. Select UserName Token as the value of Security Mechanism.
    This uses the PasswordDigest option.
  4. Enable User Authentication Required to generate a user token.
  5. Change the Name and Password values for the Credential for User Token.
    This attribute contains the shared secrets used by the WSC to generate a user token. The password should be the same as the hashed password stored in the OpenSSO configuration data store. Use ldapsearch if the data store is Directory Server. NOTE: This step is for demonstration purposes only. In real deployments, the WSC and WSP would have a common agreement about their password storage policy.
  6. Navigate to Access Control -> / (Top Level Realm) -> Authentication.
  7. Create a new authentication chain named wssauthchain.
    See Configuring an Authentication Process Using the OpenSSO Enterprise Console.
  8. Click wssauthchain in the list of authentication chains.
  9. Add WSSAuth as the required Authentication Mechanism and click Save.
  10. Navigate to Access Control -> / (Top Level Realm) -> Agents -> Web Service Provider -> wsp
  11. Select UserName Token as the value of Security Mechanism and wssauthchain as the authentication chain.
  12. Click Save.

To test the configurations, use the stock quote sample included with the Web Services Security Agent. After attempting to access the sample's main page, the user is redirected to OpenSSO for authentication. After successfully authenticating, the user is redirected back to the main page. When the user clicks the Get Quote button, stock quote values are displayed and the authentication mechanism used is displayed; in this case, Username Token with digest option. Changing the security mechanism would result in the new security mechanism being displayed. When logging is enabled, the OpenSSO logs would also have the appropriate tokens.

More romanticizing with Combo Audio performing the indy version of their tune, Romanticide for this video cover. I thought it was the real deal because the 7" single I owned back then had no band picture. Still a great tune.

Unlike the version they rerecorded after signing with a major label. This cleaner version is okay but not the bomb that was dropped when they released the original. But at least there's a video!

Tuesday Apr 28, 2009

Buddying Up for the NEW OpenSSO Resource Center

There have been changes made to the OpenSSO Resource Center. The home page might look the same but drill down deeper and you will find some new sections.
  • First and foremost, Sun OpenSSO Documentation has been moved from another (relatively new) wiki space to become buddies with the OpenSSO Resource Center.
  • The Sun OpenSSO doc team has begun the process of moving all official documentation (starting with version 8.0) to the Sun OpenSSO Documentation wiki space. All documentation moving forward will be created on wiki. Here is a direct link to the Sun OpenSSO Enterprise 8.0 Documentation Center wiki. This page has links to the documentation on as well as newer links to the wiki versions of the documentation. (The titles of wiki pages are appended with the word wiki to differentiate from those appended with the acronym dsc.) You will notice more wiki-formatted pages and less links to as the process proceeds.
  • A Community Contributions space has been added for YOU. As long as you are a registered user of, a Sun partner or a Sun employee, you can add a page and write up some content that will be helpful to the rest of the community. Or just edit the Community Contributions home page and add a link to a blog entry or other article you think might be helpful to the OpenSSO community.

    • Any information you publish as a registered wiki user can be viewed and edited by other registered wiki users. Anonymous users can view, but not edit, content.
    • Any information you publish as a Sun employee can be viewed and edited by other Sun employees only.
  • Engineering Drafts is a SUN INTERNAL site. (Sorry, externals.) Sun employees can add one-pagers, requirement specs, PRDs, and other requisite documentation to this page. Thus, all our development docs can be housed in one place. This page describes how to create an engineering draft page.

And in honor of the buddying up of two OpenSSO wikis, enjoy the buddying up of two phenomenal talents. Here's a clip of Angela Lansbury and the late, great Bea Arthur singing Bosom Buddies, the duet they originated on Broadway in the musical Mame.

Sweet Soul Revue-ing 'Organizing Data in an OpenSSO Realm'

Notwithstanding Maybe You'll Know: Logging in to the OpenSSO Console, here's another chapter from the Sun OpenSSO Enterprise 8.0 Administration Guide that has been rewritten and wiki-ized.

Organizing Data in a Realm basically takes you through the tabs that are used to configure data in a realm - everything under the Access Control tab. The simpler sections are complete in this entry while the more complex sections link to chapters on (until these chapters are also formatted for wiki).

So what's missing? Is the information organized as you might look for it when using the console? When you read a section are you wanting further information for which there is no link? Remember this is administration information when you read it - not coding or customization.

Thoughts? Comment here or on the wiki.

Coming up: Managing Authentication Using Realms

Sweet Soul Revue is a great pop song from the Japanese band, Pizzicato Five. I had a bunch of P5 albums in the 90s although I never quite knew what most of the lyrics were about. Still got me up on the dance floor!

Monday Apr 27, 2009

Maybe You'll Know: 'Logging In To The OpenSSO Console' Review

Over the next few months, the OpenSSO writer's team will be moving our deliverables from to our new documentation wiki.

I've started rewriting chapters from the Administration Guide to close a myriad of issues filed against the book so I decided to put the wiki URLs with the new text out for public review and comments. Click to read the first (albeit simple) chapter, Logging In To The OpenSSO Console.

I envision the information in Logging In To The OpenSSO Console as an explanation of the login process and what the user might see after logging in. What I am looking for from the reviewers is what other console-related infomration might be worth mentioning. This would only be from an administration/interface perspective. This is not the chapter to refer to customizing the console as that would most likely have already been done by the time an administrator begins to log in.

Thoughts? Comment here or on the wiki.

Coming later this week: Chapter 2: Organizing Data Within Realms

In the meantime, here's Cyndi Lauper as lead singer of Blue Angel performing Maybe He'll Know. She's a charmer!

Monday Apr 20, 2009

Creating an OpenSSO User Data Store Using Sun Directory Server is Like Riding a Bicycle

My instance of OpenSSO Enterprise Express Build 7 was installed with the option to use the embedded data store as a user data store. This option is for proof-of-concepts only and should not be used in real-time deployments. I wanted to check out some stuff regarding roles and, as the roles portion of OpenSSO only works with an installed Sun Directory Server, I installed Directory Server EE 6.3.

If you haven't installed OpenSSO yet, check out OpenSSO Build 2 and Glassfish: Ready to Go. It's an older entry but still works - despite the old screen shots. Once complete, proceed with the following tasks.
  1. Make a directory named ds.
  2. Download Directory Server Enterprise Edition (EE) 6.3 into the ds directory.
  3. Decompress the file.
    gunzip DSEE.6.3.Solaris-Sparc-full.tar.gz
    tar xvf DSEE.6.3.Solaris-Sparc-full.tar

    For some reason, executing gunzip and tar with one command did not work on this compressed file.
  4. Make a directory named /opt/dsee.
  5. Install the Directory Server EE software into the /opt/ds directory.
    /ds/DSEE_ZIP_Distribution/dsee_deploy install -i /opt/dsee
  6. Press Enter until you reach the end of the license agreement.
  7. Type Yes when asked Do you accept the license terms? and press Enter to execute.
  8. Make a directory in which to store Directory Server EE instances.
    mkdir /opt/dsee/instances
  9. Change to the directory that contains the dsadm command-line interface.
    cd /opt/dsee/ds6/bin
  10. Create a new instance of Directory Server.
    ./dsadm create -p 389 -P 636 /opt/dsee/instances/ example
    You will be prompted to enter a password for cn=Directory Manager.
  11. Start the example instance.
    ./dsadm start /opt/dsee/instances/example
  12. Create the dc=example,dc=com suffix.
    ./dsconf create-suffix dc=example,dc=com
  13. Type Y to accept the server certificate.
  14. Enter the Directory Manager password.
    In the next steps, you will load the OpenSSO schema and add the Directory Server instance as a user data store with the OpenSSO console.

Because my installation initially used the embedded data store as a user store I was not able to select this Directory Server instance during configuration so I had to follow the instructions, Loading the OpenSSO Schema into Sun Java System Directory Server.

Finally, add the data store to a realm. I created a sub realm to the /Top Level Realm and added the data store to the sub realm.
  1. Login to the OpenSSO console as the administrator.
  2. Click the Access Control tab.
  3. Click New under Realms, enter the appropriate values and click OK to create a sub realm.
  4. Click the name of the new sub realm.
  5. Click the Data Stores tab.
  6. Remove the embedded data store, if applicable.
  7. Click New under Data Stores.
  8. Enter a name, select Sun DS with OpenSSO Schema, and click Next.
  9. Enter the appropriate server information and click OK.

At this point, I was able to create users using the OpenSSO console and the instance of Directory Server. I did have a some issues though viewing users I had imported from an LDIF file. Trainer extraordinaire David Goldsmith gave me these tips which worked.
  • Use the fully qualified host name as a value for LDAP Server when configuring the data store.
  • Set the Persistent Search Scope attribute to SCOPE_SUB as it is the default when you connect to an external LDAP directory during configuration.
  • Remove ou and people for the LDAP people container naming value and attribute. David wrote "I have no idea of why I had to blank out the 2 people container naming fields. I tried it because I used to have to do it in 7.0/7.1 but I have not had to do it in 8.0." The interesting thing about this tip is the values for those attributes are back. Maybe during restart, the attributes were repopulated?
So in honor of David and his bicycling ways, here is Queen with Bicycle Race, complete with footage from the bicycle race that was filmed especially for this video...back in the day. Those who were around...back in the day...might remember this footage. To you others, some quick elements are NSFW.

Friday Apr 17, 2009

What a Difference Updated OpenSSO Federation Docs Make

I recently posted two updated docs from the OpenSSO Enterprise engineering team regarding the federation architecture and use cases. You can access these documents from tree or using the links below.

Now, start the weekend early, get off your chair and dance away to Esther Phillips singing her disco version of the standard What a Difference a Day Makes.

Thursday Apr 16, 2009

OpenSSO Express Build 7 is Released

So we did! Here are the link stats:

Download Link

Download Page on OpenSSO

Documentation on the new OpenSSO doc wiki.

Video of Englebert Humperdinck whose version of the standard Release Me helped to title the blog entry.

Thursday Apr 09, 2009

Roam for Centralized Error Processing in the OpenSSO SAMLv2 Service

If you want information on Centralized Error Processing in OpenSSO's SAMLv2 Service roam over to this article on for some information I just put together on the concept and configuration.

But click play for this live version of Roam performed in various venues by the B-52's before you click work.

Excellent editing, wouldn't you say?

Wednesday Apr 01, 2009

OpenSSO Special Users Are No Killing Joke

Yesterday, I installed the ssoadm command line interface and exported the configuration data from the OpenSSO embedded configuration data store. I wanted to do this so I could go through the data and find the OpenSSO special users that were created during a fresh installation of the product. Here are the users I found and some information about each.
  • The OpenSSO administrative user (as we all know) is amadmin (uid=amAdmin,ou=People,dc=opensso,dc=java,dc=net). This top-level administrator has unlimited access to all entries managed by OpenSSO. During installation, you must provide a password for amadmin. To change the password after installation, use the OpenSSO console. The amadmin profile is a Subject under the top-level realm. You cannot change the default amadmin identifier.
  • amldapuser (cn=amldapuser,ou=DSAME Users,dc=opensso,dc=java,dc=net) has read and search access to all embedded data store entries; it is used when the OpenSSO schema extends the embedded data store schema. amldapuser binds to the directory to retrieve data for the LDAP and Membership authentication modules and the Policy Configuration Service. The default password for amldapuser is changeit. You can change the password by modifying the value of the AMLDAPUSERPASSWD property in the OpenSSO-Deploy-base/opensso/WEB-INF/classes/ file BEFORE running the OpenSSO configurator. To change the amldapuser password after configuration, use ldapmodify (which is NOT supported). In the latter case, also modify the LDAP Authentication Service and Policy Configuration Service because amldapuser is the default user for these services. Make the changes in each realm in which these services are registered.
  • Proxy user (cn=puser,ou=DSAME Users,dc=opensso,dc=java,dc=net) is a proxy user that works behind the scenes for the legacy AMSDK. This user is created during installation and cannot be modified or found in the OpenSSO console.
  • UrlAccessAgent (as we all know) is the user that a web agent uses to login to OpenSSO but who is amService-UrlAccessAgent (cn=amService-UrlAccessAgent,ou=DSAME Users,dc=opensso,dc=java,dc=net)? Well, both users are the same. When entered as UrlAccessAgent on the server side, the Authentication Service prepends to it the string amService-. The Authentication Service then authenticates it is a special user with an entry in the data store. The password for UrlAccessAgent is defined during the OpenSSO configuration.
  • CN=Directory Manager,CN=Users,dc=opensso,dc=java,dc=net is the default top level administrator for Sun Directory Server with read and write access to all entries in the embedded configuration data store. This user would be used to bind to the embedded configuration data store if the OpenSSO schema is not installed.
  • CN=Administrator,CN=Users,dc=opensso,dc=java,dc=net is the default top level administrator for Microsoft Active Directory. This is similar to cn=Directory Manager for Sun Directory Server.
  • demo is the user used to demonstrate the federation-related features of OpenSSO. By default, its password is changeit. This user is displayed as a subject of the top-level realm in the OpenSSO console and its default password can be changed.
  • The test user is used to execute some OpenSSO samples. These samples would create the test user and test will be displayed as a subject of the top-level realm in the OpenSSO console after executing them. The default password for test is test.
  • dsameuser (cn=dsameuser,ou=DSAME Users,dc=opensso,dc-java,dc=net) binds to the embedded configuration data store when the OpenSSO SDK performs operations on it that are not linked to a particular user (for example, retrieving service configuration information).
  • anonymous is the default anonymous user. If the Anonymous authentication module is enabled, an anonymous user can log into OpenSSO without providing a password. You can define a list of anonymous users by adding user identifiers to the anonymous profile using the OpenSSO console.
Now, here's something for April Fools Day: Killing Joke and their song Change. Change was not on the original 1980 UK release of their debut album (eponymously titled Killing Joke) but it was on the original 1980 US release. I remember specifically buying the US release of this LP at a time when all I was buying were imports. Good times.

Tuesday Mar 31, 2009

Get Off My Case if You Can't Export OpenSSO Configuration Data

I wanted to export the configuration data on my install of OpenSSO so I went back to the directory that was created after I expanded to setup the ssoadm command line utility. Here are the steps I followed.
  1. Set JAVA_HOME and PATH variables to point to the correct version of Java; in this case, version 1.5.
    # JAVA_HOME=/usr/java/jdk1.5.0_14
    # export JAVA_HOME
    # PATH=$JAVA_HOME/bin:$PATH;
    # export PATH
  2. Create a directory into which you will expand the
    # mkdir /ssoadmtool
  3. Unzip into the top-level directory created.
    # cd /opensso/tools
    # unzip -d /ssoadmtool
    # cd /ssoadmtool
    # ls -la
    total 320
    drwxr-xr-x   6 root     root          10 Mar 31 10:42 .
    drwxr-xr-x  42 root     root          47 Mar 31 08:16 ..
    -rw-r--r--   1 root     root        4796 Mar 18 01:31 README.setup
    drwxr-xr-x   2 root     root          25 Mar 18 03:55 lib
    -rw-r--r--   1 root     root       17003 Mar 18 01:31 license.txt
    drwxr-xr-x   3 root     root           3 Mar 31 10:42 opensso
    drwxr-xr-x   2 root     root        1161 Mar 18 03:55 resources
    -rwxr-xr-x   1 root     root        2638 Mar 18 01:31 setup
    -rw-r--r--   1 root     root        3182 Mar 18 01:31 setup.bat
    drwxr-xr-x   4 root     root           4 Mar 18 01:31 template
  4. Run setup from the top-level ssoadmtool directory.
    # ./setup
    Path to config files of OpenSSO server (example: /opensso):/opensso
    Debug Directory:/opensso/debug
    Log Directory:/opensso/log
    The scripts are properly setup under directory: /ssoAdmin/opensso
    Debug directory is /opensso/debug.
    Log directory is /opensso/log.
    The version of this is: (2009-March-18 01:14)
    The version of your server instance is: (2009-March-18 01:14)
  5. Run ssoadm using the export-svc-cfg option.

    ./ssoadm export-svc-cfg -e secretenckey -o /var/tmp/config.xml -u amadmin -f /tmp/password

    • e defines the key that will be used to encrypt any sensitive information in the configuration data store.
    • o defines the name and location of the XML file to which the configuration data will be written.
    • u defines the OpenSSO administrator; by default, amadmin.
    • f defines the name and location of the file that contains the OpenSSO administrator's password.

    config.xml is created in /var/tmp and contains the configuration data stored in the OpenSSO embedded configuration data store.
Now I'm exporting (-o you) the loveliness that is the Comateens singing Get Off My Case in the old train station in Hoboken, New Jersey. They are a great band singing in a great city in an OK state. And I would know - I lived in Hoboken for three years.

Sunday Mar 29, 2009

The Computer Whisperer starring French and Saunders

Some Sunday morning laughs...unless, of course, it's your computer that isn't working.

Tuesday Mar 24, 2009

Finally an OpenSSO Upgrade Guide With No Issues

I've just finished upgrading an instance of Access Manager 7.1, documented the procedure (including the scripts and related parameters) and rewrote the OpenSSO Enterprise 8.0 Upgrade Guide based on the outcome. Check it out!

Issues fixed because of this include:
  • 4513
  • 4467
  • 4022
  • 3331
  • 4183
  • 4028
  • 4566
  • 4568
  • 4176
  • 4428
  • 4032

Now dance it out with Finally, Ce Ce Peniston's huge hit that found a home (after radio) in the film, Priscilla, Queen of the Desert.

Friday Mar 20, 2009

Heebie Jeebies! You CAN Encrypt Data in a Secure Attribute Exchange

I just posted an article documenting how to encrypt data when using the Secure Attribute Exchange (also known as Virtual Federation) gateway. It contains configuration procedures and tips on how to use the com.sun.identity.sae.api package. You can find this article on the doc wiki.

And don't forget to remember that Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 also has information on configuring and using the Secure Attribute Exchange gateway.

Now let's reach waaaaaay back - almost eighty years back! Sure the Andrews Sisters were popular but they lifted what they did from the under-appreciated Boswell Sisters. Almost ten years before the Andrews ladies had their biggest hits, Connie, Martha and Vet had a huge harmonic hit with Heebie Jeebies (amongst others). And the Boswells played their own instruments and did their own production. What a bunch of gals!

Tuesday Mar 17, 2009

Don't Ask Me Why XML Signing and Encryption in a Fedlet is Not Here

This is the first blog entry in which I will be using links to articles I've posted on Moving forward the OpenSSO writers are going to be collecting documentation, articles and the like over there. I will though continue to blog these links because I know there must be one or two of you out there who would miss the music lessons.

The first article I've published is titled Enabling XML Signing and Encryption in a Fedlet and explains the titular procedure.

The first musical interlude in this new way of working is Don't Ask Me Why performed by Eurythmics. From 1980 through 1991 I saw Eurythmics in concert five times and there was not a bad performance in the bunch. Live vicariously now through this live version.

Monday Mar 09, 2009

Pop, OpenSSO Account Lock(out) and Drop

The OpenSSO Authentication Service provides a feature where a user will be locked out from authenticating after a defined number of failures. (More information is in the Sun OpenSSO Enterprise 8.0 Administration Guide.) When account lockout is enabled an attribute in the user data store is used to hold information regarding the authentication attempts. This information includes:
  • invalid attempts count
  • last failed time
  • lockout time
  • lockout duration
Many businesses have user data stores already configured for their overall deployment. If this is the case, the administrator might not want to (or need to) load the OpenSSO schema. The following procedure can be used to configure the account lockout feature to write this information to an attribute not defined by the OpenSSO schema.
  1. Login to the OpenSSO console as the administrator; be default, amadmin.
  2. Click the Realm tab.
  3. Under the Authentication tab, click Advanced Properties.
  4. Select Login Failure Lockout Mode to enable account lockout.
  5. On the same page, configure Invalid Attempts Data Attribute Name.

    Invalid Attempts Data Attribute Name is used if the OpenSSO schema is not loaded. Set the value of this property to the attribute name of your choice and OpenSSO will store the data as the value of this attribute. Note that the attribute you specify needs to also be defined in the LDAP User Attributes property of the data store configuration if the data store type is either Active Directory, Generic LDAPv3 or Sun DS with OpenSSO schema.

    NOTE: Store Invalid Attempts in Data Store is selected by default and enables the storage of the data as the value of the sunAMAuthInvalidAttemptsData attribute in the user data store. In order to store data in this attribute, the OpenSSO schema has to be loaded.

Now for those who can lock it, pop and drop it with some old skool funk, Peace Pipe by B.T. Express.

Wednesday Mar 04, 2009

Free OpenSSO Enterprise Training in San Francisco, CA

The week of April 6, Sun Learning Services is holding a five day training course for newbies to OpenSSo Enterprise 8.0. See the announcement posted on the OpenSSO web site.

And since the five day course is free, how about Queen and their song I Want to Break Free - a shocking video in America when it was first televised. Can this country be anymore provincial? (No answer necessary.)

Wednesday Feb 25, 2009

A Ticket to Localizing the OpenSSO Login Page

The mysterious Gina C, my compatriot in OpenSSO technical writing, has added an article to the 8.0 documentation called Localizing the Sun OpenSSO Enterprise 8.0 Login Page. It documents how to customize an OpenSSO Enterprise login page to contain localized text. Check it out.

And, since I know Gina C is a big Beatles fan, here's some live footage of the Beatles singing Ticket to Ride. If you listen closely you can hear Gina screaming.

Book title updated: 3/10/09)

Monday Feb 23, 2009

Keystores and Certificate Alias Foundations for Web Services Security

Keystores and certificate aliases are using by OpenSSO when securing (through signing and encryption) web service requests and responses for purposes of web services security. The default certificate alias used by the Security Token Service is test. The Security Token Service uses the keystore location, keypass and storepass from the central server configuration. This data is also used by the token implementation for signing the generating the security token. The agent profiles available for Web Services Security (WSCAgent, WSPAgent and STSAgent) uses either of the following keystores:
  • If the configuration property useDefaultStore is set to true, these profiles will use the keystore location, keypass and storepass defined by the file configured local to the WSC, WSP and STS client installs. (The WSC, WSP and STS client communicate with OpenSSO using openssoclientsdk.jar and
  • You can also define a custom keystore location, keypass and storepass when you configure the agent profiles directly using the OpenSSO console. These values take precedence over the values in the client side

The PrivateKeyAlias and PublicKeyAlias can also be defined when you configure the profiles directly. You configure them for either the default or custom keystore. You can have different alias from same keystore. By default, the value is test since by default the keystore is the default keystore.

Now here's a clip of The Foundations singing Baby, Now That I've Found You.

Monday Feb 09, 2009

Deployment Example 2: SAE Expanded, Not Reduced

Some additional procedures have been made to the Secure Attribute Exchange (aka Virtual Federation) section of Deployment Example 2: SAML v2 Using Sun OpenSSO Enterprise 8.0. The section has been reorganized and changes made to 13.2 and 13.3, the identity provider and service provider configuration sections. You can see the new HTML version here on tomorrow but you can download the new PDF from OpenSSO now.

And since SuperPat scoffs at my description of The Enemy as being old-school punk (pulling out his Coventry cred, no less) I decided to embed some real punk I happen to see back in the day (pulling out my CBGB cred, no less) from the Dead Boys. Check out Sonic Reducer.

Friday Feb 06, 2009

The OpenSSO Cache is Not The Enemy

A cache is a collection of frequently accessed data that duplicates original values computed earlier and stored in a main memory store. In a write-through cache, every write to the cache causes a synchronous write to the main memory store. In a write-back cache, writes are not immediately mirrored to the store; the cache tracks which of its data locations have been written over and the data in these locations is collected and written to the main memory store all at once. A clean entry accurately reflects the contents of the main memory store and a dirty entry does not.

Two main OpenSSO components that rely heavily on caching are the Service Management and Identity Repository classes. When caching is enabled and a client invokes these services, the resulting session data is captured by the Client SDK and written to its local cache. To enable caching for the service management and identity repository services on the machine in which the Client SDK is installed, a combination of true and false values for the following properties are defined in on the Client SDK host machine.

NOTE: is used to store configuration data for the Client SDK (for example, the information needed to point the Client SDK to a remote instance of OpenSSO) and must be accessible from the machine on which the Client SDK is hosted. It is created during installation of the Client SDK.

  • enables both caches when set to true (default). A value of false disables both caches.
  • com.sun.identity.idm.cache.enabled controls the Identity Repository cache. When is set to false, enable the Identity Repository cache ONLY with a value of true. A value of false keeps it disabled.
  • controls the Service Management cache. When is set to false, enable the Service Management cache ONLY with a value of true. A value of false keeps it disabled., also in, limits the size of the Identity Repository cache to, by default, 10000 entries. There is no corresponding entry to limit the cache size for the Service Management cache.

When caching is enabled, OpenSSO has three options that can be used to invalidate dirty cache entries. The first is to set up a URL with which the OpenSSO server can send session change notifications to clients on remote web containers. This works for web and standalone applications that can listen for HTTP(s) traffic. The second method (which works ONLY if notification is disabled) is polling. In this case, the client periodically checks the OpenSSO server for session changes. The third method is referred to as Time-to-Live (TTL) and enforces a limit on the period of time dirty data remains in the cache before it is discarded. See the following sections for more information.

Configuring for Notification

OpenSSO allows for session notifications to be sent to remote web containers running the OpenSSO Client SDK in order to sync up the client side cache. The notifications apply to information from the Session, Policy and Naming Services. The following properties relate to notification and are configured on the machine in which the Client SDK is installed.

  • com.sun.identity.client.notification.url defines the URI of the Notification Service running on the host machine on which the Client SDK is installed; by default, http://SDK-host.domain:port /opensso/notificationservice. This value is used for both the Service Management and Identity Repository caches. If no URL is specified, notification is disabled.
  • com.sun.identity.idm.remote.notification.enabled is used to enable or disable the notifications for the Identity Repository cache. If set to true notifications are enabled; false disabled. If there is no value defined, it defaults to true.
  • is used to enable or disable the notifications for the Service Management cache. If set to true notifications are enabled; false disabled. If there is no value defined, it defaults to true.

There are additional steps you might need to follow to enable notification. These are documented in the OpenSSO Enterprise 8.0 Developer's Guide.

Configuring for Polling

OpenSSO allows the Client SDK to periodically check for changes to information stored in the Service Management and Identity Repository caches. Polling is enabled when notification is disabled - com.sun.identity.client.notification.url contains no value. The following properties relate to polling and are configured on the machine in which the Client SDK is installed.

  • is the time (in minutes) that the Service Management cache will poll for updates.
  • is the time (in minutes) that the Identity Repository cache (and the legacy AM SDK classes cache) will poll for updates.

Configuring Time-to-Live

The manner in which the entries in the cache are invalidated (the data's time-to-live, as it were) depends on the configuration of the following properties in the configuration data store (by default, embedded) on the machine in which OpenSSO is installed.

  • com.sun.identity.idm.cache.entry.expire.enabled takes a value of true or false which enables or disables respectively the Identity Repository TTL feature.
  • com.sun.identity.idm.cache.entry.default.expire.time specifies the time (in minutes) that non-user Identity Repository cache entries remain valid after their last modification. In other words, after the specified time (by default, one minute) has elapsed (following a modification or directory read), the data for the cached entry will expire and new requests for this data must be read from the directory.
  • com.sun.identity.idm.cache.entry.user.expire.time specifies the time (in minutes) that user Identity Repository cache entries remain valid after their last modification. In other words, after the specified time (by default, one minute) has elapsed (following a modification or directory read), the data for the cached entry will expire and new requests for this data must be read from the directory.
  • takes a value of true or false which enables or disables respectively the Service Management TTL feature.
  • specifies the time (in minutes) that Service Management cache entries remain valid after their last modification. In other words, after the specified time (by default, 30 minutes) has elapsed (following a modification or directory read), the data for the cached entry will expire and new requests for this data must be read from the directory.
  • NOTE ON LEGACY SUPPORT: To enable TTL for the classes, configure,, and

Sample Configuration

The following configuration enables caching and updates using the server side TTL properties and the client side Service Management polling.

  1. Enable caching for Service Management and Identity Repository

    • com.sun.identity.idm.cache.enabled=true
  2. Disable notifications for Service Management and Identity Repository

    • com.sun.identity.idm.remote.notification.enabled=false
  3. Enable TTL for Service Management, Identity Repository and, if desired, the legacy AM SDK.

    • com.sun.identity.idm.cache.entry.expire.enabled=true
    • com.sun.identity.idm.cache.entry.user.expire.time=1
    • com.sun.identity.idm.cache.entry.default.expire.time=1

  4. Enable polling for Service Management and disable polling for Identity Repository


The Enemy

Now check out the old school punk of The Enemy (aka The Enemy UK on this side of the pond) on We'll Live and Die In These Towns.

Wednesday Jan 28, 2009

Scott McNealy and Barack Obama: They're Going To Be Friends

Interesting article on what Scott McNealy is up to lately: working with the new Prez.

And here's the White Stripes reading - and performing We're Going To Be Friends.

Tuesday Jan 27, 2009

Customize an OpenSSO IDPAttributeMapper For Once

To implement a federated solution where the consumer of a service can select which attribute is sent from the identity provider to the service provider as an assertion write a custom IDPAttributeMapper . The getAttributes() method takes the OpenSSO SSOToken as one of its parameters. From this, you can determine who the end user is, pull the correct attributes for that user and return the values as an attribute list. The identity provider will take the attributes and send them to the service provider as part of a SAMLv2 assertion.

Once you've finished, check out the video for the Academy Award-winning song from the movie Once. Excellent film about two people Falling Slowly in love. The love segued into real life until last night when I read that Glen Hansard and Marketa Irglova were no longer a couple. Worse things have happened but they were a sweet couple in the film.




« July 2016