Monday Aug 10, 2009

Store & Retrieve Authentication Info with OpenSSO, She & Him

Here are some words on storing authentication information in an OpenSSO session and retrieving it. It assumes that the authentication module extends AMLoginModule and the information is to be shared with a post authentication plug-in.

If the size of the information is small, you can store it in the SSOToken. If the information is security sensitive and not to be readable by the Client SDK, you could encrypt it before setting it in the SSOToken. (Prefixing the property name with am.protected. defines it as NOT readable by the Client SDK.)

After you put the required information from the authentication module into the module principal class, implement the com.sun.identity.authentication.service.AuthenticationPrincipalDataRetriever interface. It has the following method to get the module principal from authSubject, retrieve the required data, and return that data as a Map (key/value pairs).
     \* Returns the attribute map from the required Authentication module
     \* Principal, to be set in the SSOToken.    
     \* @param authSubject Authenticated user Subject.
     \* @return the Attribute Map.
    Map getAttrMapForAuthenticationModule(Subject authSubject);
The Authentication Service will store this Map in the authenticated SSOToken. A post authentication plug-in can retrieve this data from the SSOToken later. You will need to set your implementation class as a value of the com.sun.identity.authentication.principalDataRetriever property in the OpenSSO configuration data store.

Now here is Zooey Deschanel and M. Ward, plugged in as She & Him. Why Do You Let Me Stay Here? is from their album, Volume 1. I love M (especially his album Transistor Radio), love Zooey (especially as an actress in the ScyFy take on Oz called Tin Man) and also Zooey's sis, Emily (especially as the femme lead on Bones). The video is quirky and endearing and bloody.

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.

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.

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.

Friday Jan 23, 2009

Testing The Sweet OpenSSO SAMLv2 Name Identifiers

The SAMLv2 Name Identifier Management Profile documents how an identity provider and a service provider might inform each other of changes to the identifier that they reference when communicating about a particular identity. The various OpenSSO ManageNameID (MNI) JSP provide a way to change SAMLv2 name identifiers or terminate mappings between identity provider accounts and service provider accounts. For example, after establishing a name identifier for use between providers when referring to an identity in SAMLv2 communications, an identity provider may want to change the value and/or format. The identity provider will notify service providers of the change by sending them a ManageNameIDRequest. A service provider might also use this message type to register or change the SPProvidedID value (included when the underlying name identifier is used to communicate with it) or to terminate the use of a name identifier between itself and the identity provider.

Following is a procedure that can be used to test the profile using OpenSSO. In the example procedure, is the identity provider and is the service provider.

  1. Initiate single sign-on and account linking (federation) from the service provider side using

    spSSOInit.jsp is used to initiate single sign-on and federation on the service provider side. Because metaAlias and idpEntityID are defined, the request is created and sent to the identity provider. This links the two accounts and creates a name identifier to be used by the providers to refer to the identity during communications. Both providers keep the name identifier in the user's profile which makes the format persistent.
  2. Log in to the identity provider host machine and the service provider host machine as root.
  3. Run
    ldapsearch -h maple -D "cn=directory manager" -w password -p 389 -b "dc=sun,dc=com" "uid=\*" sun-fm-saml2-nameid-info sun-fm-saml2-nameid-infokey
    on each host machine to view the values for the sun-fm-saml2-nameid-info and sun-fm-saml2-nameid-infokey properties.

    • On the identity provider side, sun-fm-saml2-nameid-info will have a value similar to||

      On the service provider side, sun-fm-saml2-nameid-info will have a value similar to||

      sun-fm-saml2-nameid-info is used to store all information related to the name identifier. The value is formatted as:



              hosted_entity_id    : entity id for this hosted entity
              remote_entity_id    : entity id for the remote entity
              idp_nameid          : name identifier for the IDP
              idp_nameid_qualifier: nameid qualifier for the IDP
              idp_nameid_format   : nameid format for the IDP
              sp_nameid           : name identifier for the SP/Affiliation
              sp_nameid_qualifier : nameid qualifier for the SP/Affiliation
              hosted_entity_role  : SPRole or IDPRole, useful when one entity could be IDP and SP at same time.
              is_affiliation      : true for affiliation, false otherwise 
    • On the identity provider side, sun-fm-saml2-nameid-infokey will have a value similar to||

      On the service provider side, sun-fm-saml2-nameid-infokey will have a value similar to||

      sun-fm-saml2-nameid-infokey is used to search an LDAP data store for better performance, when that type of data store is used. The user that binds to the LDAP data store must have read/write/search/compare permission to this attribute. You must also must make sure that the equality type index is added to the data store. The value is formatted as:



              hosted_entity_id    : entity id for this hosted entity
              remote_entity_id    : entity id for the remote entity
              idp_nameid          : name identifier for the IDP
  4. Terminate the link (defederate) between the user's service provider and identity provider accounts using one of the following URLs referencing spMNIRequestInit.jsp.

    • Initiate defederation from the service provider using either HTTP-Redirect binding or SOAP binding respectively:
    • Initiate defederation from the identity provider using either HTTP-Redirect binding or SOAP binding respectively:
  5. After defederation, run the previous ldapsearch command again.

    The two properties have no values on both the identity provider and service provider sides.
  6. Federate the user's service provider account and identity provider account again using the URL that references spSSOInit.jsp.
  7. Run the previous ldapsearch command again.
    The two properties have values on both the identity provider and service provider sides again; the value of the name identifier is different from the previous value.
  8. Initiate the creation of a new name identifier using one of the following:

    • Initiate the creation of a new name identifier from the service provider side using spMNIRequestInit.jsp and the following URL:
    • Initiate the creation of a new name identifier from the identity provider side using idpMNIRequestInit.jsp and the following URL:
  9. Run the previous ldapsearch command for a third time.
    The two properties have values on both the identity provider and service provider sides; the value of the new name identifier is different from both of the previous values.

More information on the JSP can be found in the OpenSSO Enterprise 8.0 Administration Guide.

And, in keeping with the sweet theme of the host machine names, here's The Sweet with Fox on the Run. I still smell hamburgers when I hear this song - high school lunches at the coffee shop with a jukebox.

Tuesday Jan 20, 2009

Fedlet or Policy Agent? AND BARACK!

Rajeev Angal wrote an interesting answer in an email when asked the question What is the advantage of using the Fedlet versus installing a policy agent on the partner website? I thought the information was worth double-dipping.

A Fedlet allows you to:
  • Use SAMLv2 standards to accomplish single sign-on - keeping the partner domains separate.
  • Add privacy and security characteristics to the deployment involving loose coupling between the partner domains.
  • Integrate with an existing application that already has session management.

A policy agent is a better option if:
  • The two domains are owned by the same business.
  • You want session and related services (user profile, configuration etc) to be accessible from the partner domain.
  • Access between the agent in one domain and the OpenSSO server on the other is secure.
NOTE: If you also have the option to install an instance of OpenSSO in the partner domain, the two servers connect using SAMLv2 (just like the Fedlet/OpenSSO case) except that the domain can make full use of the session and other facilities (isolated from OpenSSO in the other domain) although at the cost of a slightly more complex deployment at the partner end.

Today, in honor of the 56th Presidential inauguration and the ascension of Barack Obama and Joseph Biden to the offices of President and Vice President respectively, here is a music video I created during the campaign. The song is A Change in the Wind and is sung by Face to Face. The images speak for themselves.

Friday Jan 16, 2009

OpenSSO Security Product of the Year: A Cool Place to Be

If you haven't seen Pat's blog entry then you might not know that OpenSSO Enterprise won Security Product of the Year 2009. (2009? Whatever.) Congratulations to all coding peeps, doc nerds, quality analyzers, marketing gurus, virtual architects, and repeat voters. It's a cool place to be.

And if you've already seen the news, go to other Cool Places with Sparks and Jane Weidlin (of The Go-Go's). Very rare and very 80s.

NOTE: Really into this song? Search for the Sparks and the Go-Go's live versions. The Sparks video is from MTV in its heyday and is excellent; the Go-Go's not so much although it is interesting to hear it sung by Belinda Carlisle in 2006!

Thursday Jan 15, 2009

More, More, More Custom OpenSSO Authentication Modules

OpenSSO Enterprise provides the com.sun.identity.authentication.spi package to write Java-based authentication modules and plug them into the Authentication Service framework, allowing proprietary authentication providers to be managed using the OpenSSO Enterprise console. The authentication module is created using the abstract com.sun.identity.authentication.spi.AMLoginModule class which implements the JAAS LoginModule class.

com.sun.identity.authentication.spi.AMLoginModule provides methods to access the Authentication Service and the authentication module's callback requirements file. Once created, a custom authentication module can be added to the list of authentication modules displayed by the OpenSSO Enterprise console. Use the following list of procedures as a checklist to create and integrate a custom authentication odule into OpenSSO.

  1. Create a callback requirements file for the new authentication module.
    The authentication module's callback requirements file is written in XML and defines the module's authentication requirements and login state information. The parameters in this file automatically and dynamically customize the authentication module's user interface in the form of login pages that provide the means to initiate, construct and send credential requests to the Distributed Authentication User Interface. When an authentication process is invoked, the values nested in the Callbacks element of the module's configuration properties file are used to generate login screens. The module controls the login process, and determines each concurring screen. The callback requirements file included with OpenSSO and the corresponding DTD (Auth_Module_Properties.dtd) can be found in the source code and used as a template for creating a new one.
  2. Implement a Principal class.
    Write a class which implements to represent the entity requesting authentication. For example, the constructor takes the username as an argument. If authentication is successful, the module will return this principal to the Authentication Service which populates the login state and session token with the information representing the user.
  3. Create a service file for the new authentication module.
    The authentication module's service file is written in XML and imported to OpenSSO to allow the management of its attributes using the OpenSSO console. The name of the service file follows the format amAuthmodulename.xml (for example, amAuthSafeWord.xml or amAuthLDAP.xml). The service files included with OpenSSO and the corresponding DTD (sms.dtd) can be found in the source code and used as a template for creating a new one. You can also cut, paste and modify the following template.
  4. <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ServicesConfiguration
    PUBLIC "=//iPlanet//Service Management Services (SMS) 1.0 DTD//EN"
    <Service name="iPlanetAMAuthMYMODULEAuthService" version="1.0">
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-server"
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-base-dn"
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-search-base-dn"
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-bind-dn"
    <Value>cn=Directory Manager</Value>
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-primary-bind-passwd"
    <AttributeSchema name="iplanet-am-auth-mymoduleauth-auth-level"
    <OrganizationConfiguration name="/">
    <Attribute name=
  5. (OPTIONAL) Create a localization properties file for the new authentication module.
    A localization properties file specifies the screen text that an administrator will see when directed to an authentication module's service page in the OpenSSO console, as well as messages (error or otherwise) displayed by the module. Here are some concepts behind the creation of this file.

    • The data following the equal (=) sign in each key/value pair could be translated to a specific language as necessary.
    • The alphanumeric keys (a1, a2, etc.) map to fields defined by the i18nKey attribute in the corresponding amAuthmodulename.xml service file.
    • The alphanumeric keys also determine the order in which the fields are displayed in the OpenSSO console. The keys are taken in the order of their ASCII characters (a1 is followed by a10, followed by a2, followed by b1). For example, if an attribute needs to be displayed at the top of the service attribute page, the alphanumeric key should have a value of a1. The second attribute could then have a value of either a10, a2 or b1, and so forth. The files are located in OpenSSO-Deploy-base/WEB-INF/classes and follows the naming format; for example,

    Use one of the provided authentication module localization properties files in the source code as a template for creating the file and copy it to the aforementioned directory when complete.
  6. Develop the custom authentication module.
    Custom authentication modules extend the com.sun.identity.authentication.spi.AMLoginModule class and must implement the init(), process() and getPrincipal() methods. The module should also invoke the setAuthLevel() method. Other methods that can be implemented include setLoginFailureURL() and setLoginSuccessURL() which define URLs to which the user is sent based on a failed or successful authentication, respectively. To make use of the account locking feature with custom authentication modules, the InvalidPasswordException exception should be thrown when the password is invalid.
  7. (OPTIONAL) Add post processing features.
    The com.sun.identity.authentication.spi.AMPostAuthProcessInterface interface can be implemented for post processing tasks on authentication success, failure and logout using the methods onLoginSuccess(), onLoginFailure(), and onLogout(), respectively. The Authentication Post Processing Classes are defined in the Core Authentication Service and configurable at several levels such as at the realm or role levels.
  8. Access http://osso-host.osso-domain:osso-port/opensso/ssoadm.jsp from a browser and choose create-svc to create the service in OpenSSO.
    Copy the authentication module's service file to the text box.
  9. Choose the register-auth-module option (also on ssoadm.jsp) to register the custom authentication module with the Core Authentication framework.
    Enter the complete module name including the prepended package.
  10. Restart OpenSSO.
    The custom authentication module is now listed under the Configuration tab as an Authentication option.

NOTE: After deploying opensso.war, you can also point a browser to http://osso-host.osso-domain:osso-port/opensso/ samples/authentication/AuthSampleLoginModule to access the sample, How to Write Sample LoginModule using AMLoginModule SPI (Service Provider Interface).

Now enjoy the More, More, More, the Andrea True Connection's #1 hit from 1976. That's when sex stars had class! (But where's the Connection?)

Wednesday Jan 14, 2009

Like to Get to Know You at the OpenSSO Webinar

A week from today (January 21, 2009) at 10 AM PT, Daniel Raskin (The Smoking Monkey) and Jamie Nelson (OpenSSO Director of Engineering) will be hosting an OpenSSO webinar titled Access Management, Federation, and Secure Web Services with OpenSSO Enterprise. During this session, they will discuss OpenSSO innovations and how the software pushes access management, federation, and web services security to a new level. Register for the webinar here; you just might learn something new.

And now for something old you might not know about: Spanky & Our Gang performing Like to Get to Know You.

Tuesday Jan 13, 2009

Use SOAP 1.1 with OpenSSO Security Token Service

OpenSSO Enterprise 8.0 contains a Security Token Service. The Security Token Service verifies the credentials in a request presented by a web services client and, in response, issues a security token to provide proof that the client has authenticated with the Security Token Service. The web services client presents the security token to the web service which verifies that it was issued by a trusted Security Token Service. SOAP enables the exchange of these messages using a variety of underlying protocols. Out of the box, the Security Token Service supports SOAP 1.2 as a binding, a formal set of rules for transporting the messages. In order to enable SOAP 1.1 as a binding, make the following changes to before deploying the OpenSSO WAR.
  1. Download and unzip
  2. Extract the contents of opensso.war using the jar command.
  3. Change into the WEB-INF/wsdl directory.
  4. Replace the default famsts.wsdl with the modified famsts.wsdl available here.

    Backup the original famsts.wsdl.
  5. Change into the WEB-INF directory.
  6. Replace the default sun-jaxws.xml with the modified sun-jaxws.xml available here.

    Backup the original sun-jaxws.xml.
  7. Modify the web.xml also located in the WEB-INF directory by adding the following two entries to the file as positioned below.

  8. Archive a modified opensso.war, deploy it as usual and OpenSSO will be ready to use SOAP 1.1 as a binding for the Security Token Service.

Keeping in the SOAP mode, here's the Buggles performing their 1980 hit Clean Clean.

Monday Jan 12, 2009

Give Him OpenSSO Resource-based Authentication

Policy agents deployed to web containers and web proxy servers protect content from unauthorized intrusions. Access to this content (services, for example) are controlled through policies configured with OpenSSO. Here is a description of the interactions that occur when a policy agent interacts with OpenSSO.
  1. A policy agent intercepts the user's request and validates any authentication credentials contained within it. If the existing authentication level is insufficient, the OpenSSO Authentication Service will present a login page for an authentication upgrade. The login page prompts the user for the credentials appropriate to the configured module.
  2. The Authentication Service verifies that the user credentials are valid. For example, the LDAP authentication module verifies that the user name and password are the same as those stored in the LDAP identity data store. If other authentication modules are passed to the user (such as RADIUS or Certificate), the credentials are verified with the appropriately configured identity data store.
  3. Assuming the user's credentials are properly authenticated, the policy agent examines the policies assigned to the user.
  4. Based on the aggregate of the user's configured policies, the individual is either allowed or denied access to the resource.

NOTE: In this scenario, if the user attempts access to a web resource without authentication credentials, the agent redirects the user to the login page of the default authentication module. (Even if the resource is protected by a different authentication module, the user must first authenticate using the default authentication module.)

Because some customers require a scenario in which the user authenticates against a particular module based on the resource being accessed, the Gateway servlet provides resource-based authentication; there is no need for the user to authenticate to the default authentication module to access the protected web resource. When using the Gateway servlet:
  • A web resource can not be defined in more than one policy. For example, if abc.html is defined in a policy definition as requiring LDAP authentication, abc.html can not be defined in a second policy definition as requiring Certificate authentication.
  • You can use the level and scheme conditions only when defining policies that the servlet will examine.
Additionally, the Gateway servlet does not work across internet domains. Use the following list to configure your deployment to use the Gateway Servlet.
  1. Configuring the Web Container
  2. Configuring OpenSSO
  3. Configuring the Policy Agent
  4. Testing the Servlet
Configuring the Web Container

Generically speaking, you must ensure the following configurations on your web container. Check your container's documentation for information on how to do them.
  1. Check that the following certificates are installed:

    • A certificate for the server (Server-Cert).
    • A certificate for the trusted Certificate Authority.
  2. Add a listen socket for simple Secure Sockets Layer (SSL) and one for SSL client authentication.
  3. Ensure that the listener port configuration requires SSL for client authentication.
Configuring OpenSSO

  1. Log in to the OpenSSO console as the administrator.
  2. Click the Configuration tab and the Authentication tab under it.
  3. Click the Certificate Service Name link.
  4. Enable Match Certificate in LDAP by checking the box.
  5. Select Subject UID as the value for Certificate Field Used to Access User Profile.
  6. Enter 54430 as a value for SSL Port Number.
    This port number must match the port number used for the web container's SSL client authentication listener port in the previous procedure.
  7. Type 2 as the value for the Authentication Level attribute.
    The value used must be greater that the level defined for LDAP authentication.
  8. Click Save.
  9. Click Back to Service Configuration.
  10. Under the appropriate realm, add policies for three URL resources:

    1. policy1 has a condition of LDAP authentication only for http://agent-machine.domain/banner.html.
    2. policy2 has a condition of Cert authentication only for http://agent-machine.domain/banner2.html.
    3. policy3 has a condition of LDAP authentication and a level of Certificate authentication for http://agent-machine.domain/banner3.html.
See the OpenSSO Enterprise 8.0 Administration Guide for the official documentation on configuring OpenSSO Enterprise 8.0 for resource-based authentication.

Configuring the Policy Agent

  1. Go to the installation directory for the agent protecting the resource on the web container host machine. For example, on Application Server, change to AppSvr-Directory/agents/j2ee_agents/appserver_v9_agent/Agent_001/config/.
  2. Change the value for from http://machine-name.domain:port/opensso/UI/Login to http://machine-name.domain:port/opensso/gateway in It is the only change to the policy agent configuration.
Testing the Servlet

After these configurations, the test results are:

  • Access to resource A is permitted only after successful LDAP authentication.
  • Access to resource B is permitted only after successful Certificate-based authentication.
  • Access to resource C is permitted only after both successful LDAP and Certificate-based authentication.

Now that you've configured and tested resource-based authentication, the Shangri-Las are gonna give you a great big kiss with Give Him a Great Big Kiss. I was reminded of this song when it was used in a movie I saw this weekend called Stonewall, an account of the Stonewall riots of 1969. Worth checking out!

Friday Jan 09, 2009

SAMLv2 Assertion Failover in OpenSSO

SAMLv2 Assertion Failover, when enabled, redirects a request for an assertion to a second identity provider if the identity provider that initially created the assertion is out of commission. The feature piggybacks on OpenSSO Session Failover configuration by using the same databases. Here is the procedure to configure and test SAMLv2 Assertion Failover.
  1. Deploy 2 instances of OpenSSO Enterprise to act as identity providers and 1 load balancer in front of them.
  2. Set up the entities as a site with servers (using the OpenSSO console) and confirm that the configurations work.
  3. Install and setup session failover as documented in the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
  4. Deploy 1 instance of OpenSSO Enterprise to act as service provider.
  5. On all three provider instances of OpenSSO, enable SAMLv2 Assertion Failover.
    1. Log in to the OpenSSO console as administrator.
    2. Click the Configuration tab.
    3. Click the Global tab.
    4. Click the SAMLv2 Service Configuration link.
    5. Check the box next to Enable SAMLv2 Failover.
    6. Click Save.
    7. Log out of the console.
  6. Configure each server instance of OpenSSO as the appropriate entity provider and member of the same SAMLv2 circle of trust.
  7. Export the entity provider metadata from all three server instances of OpenSSO.
  8. Load the service provider and identity provider metadata on the respective instances of OpenSSO and on the load balancer.

    You need to create the metadata for the load balancer. See your load balancer's documentation for more information. Make sure you change the URL values in the load balancer metadata from the OpenSSO instances behind the load balancer to the load balancer URL itself.
  9. Modify the spAssertionConsumer.jsp on the service provider machine to add sleep that allows enough time to shutdown the identity provider on which the request will land. (See step 11.)

    Object newSession = null;
    SAML2Utils.debug.error("Before sleep Assertion Failover");
    SAML2Utils.debug.message("Before sleep Asserion Failover");
    SAML2Utils.debug.error("After sleep Assertion Failover");
    SAML2Utils.debug.message("After sleep Asserion Failover");
  10. Initiate single sign-on using the following URL: http://host-machine.domain:port/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=

    Before proceeding to the next step, run tail on the SAMLv2 debug logs (located in OpenSSO-install-directory/opensso/debug) on the identity provider host machines to see where the single sign-on request lands.
  11. After providing the service provider user credentials, monitor the log and shutdown the identity provider on which the initial single sign-on request landed.

    Make sure the user is not federated before shutting down the identity provider. The sleep time added to spAssertionConsumer.jsp in the previous step should allow enough time for this. (See step 9.)
  12. Verify that federation successfully occurs after the identity provider is shutdown. This confirms that assertion failover was successful.
  13. Initiate single logout using the following URL:

  14. Bring the previously shutdown identity provider back up and, once again, initiate single sign-on again using the following URL:

  15. Monitor the log and shutdown the identity provider on which this second single sign-on request landed.
  16. Initiate single logout using the following URL:

  17. A successful logout confirms assertion failover is working.

And now that Assertion Failover has been correctly configured, put your footsies up and check out this live version of The Killers' latest hit - are we Human or are we dancer?

Wednesday Jan 07, 2009

Which OpenSSO Version Is Running (Up That Hill)?

Want to confirm (or even find out) what version of OpenSSO you installed many moons ago and are still running? Put the following URL in your browser:


When I ran it I received the following output in the browser window because I installed a post-OpenSSO Enterprise 8.0 build:

(2008-November-22 01:14)

Someone running OpenSSO Enterprise 8.0 would see:

Enterprise 8.0 Build 6(2008-October-31 09:07)

And once you know what version is running, keep going up that hill with Kate Bush.

Or with Placebo who recorded the more recent cover of Running Up That Hill.

Sunday Jan 04, 2009

I Will Follow the OpenSSO Training

I was searching YouTube and found that basicallythis had taken the free training and uploaded three videos documenting his experiences. The videos are silent but might be of help if you get stuck.

Lab 1, Exercise 1

Lab 1, Exercise 2

Lab 1, Exercise 3

Now check out this 1980 clip of U2 performing I Will Follow. I remember seeing them on their first tour of the US in a barely full nightclub on Long Island. My sister still shudders when I remind her of how I asked her to join me to see her now-favorite-group and she replied, "I don't even know who they are. I'll skip it."

Tuesday Dec 09, 2008

Integrating OpenSSO and .NET Cheaply and Cheerfully

OpenSSO can be integrated with .NET applications. Here are some ways to achieve single sign-on or attribute sharing:

  1. Install the IIS agent to protect the .NET application, and install OpenSSO as the service provider with the .NET application. The identity provider could then achieve single sign-on with the .NET application, and attributes can be passed down, as part of the HTTP header, to the .NET application.
  2. Securely exchange attributes using the .NET client API provided by OpenSSO for integration with the .NET application. This makes use of the SAMLv2 and the Virtual Federation Proxy feature of OpenSSO.
  3. Deploy Active Directory Federation Services as the service provider with the .NET application. OpenSSO would act as the identity provider. Use the WS-Federation protocol to achieve single sign-on with the .NET application.

While ruminating these options, enjoy Cheap and Cheerful from The Kills EXCELLENT third album Midnight Boom.

Monday Dec 08, 2008

OpenSSO Servers and Sites Configuration with SSL and SSQ

Here is some information regarding how you might configure OpenSSO sites and servers for a sample SAMLv2 deployment. The requirement in this SAMLv2 deployment is to allow normal users to access OpenSSO via pure SSL and administrative users to access OpenSSO via SSL with certificate authentication. The deployment is a straight forward setup (using two instances of OpenSSO and Glassfish, and one load balancer) except for the following:
  1. The requirement for certificate authentication for one group of users and LDAP authentication for t'other group of users.
  2. The users are split into two domains: one for the identity provider and t'other for the service provider. The identity provider will authenticate, and the service provider will control access using a J2EE policy agent.
The load balancer should be configured with two listening sockets but there should be only one configured Site in OpenSSO. The Site configuration does not need to know both listening sockets as long as the two configured listening sockets (in this example, port 1443 and 2443) point to the same instance of OpenSSO. For this deployment do the following configurations.
  • On both instances of OpenSSO, under the Configuration --> Servers and Sites tabs in the console, create one New Server for each OpenSSO instance as in:


    Create a New Site with your chosen name and a Primary URL that points to the first virtual IP of the load balancer as in Click the created Site and add the second virtual IP of the load balancer,

    Click each server previously created to add the created Site as the value of the Parent Site attribute.
  • In the first instance of the Glassfish console, configure two listening sockets:


    In the second instance of the Glassfish console, configure two listening sockets:

  • In the load balancer, configure two virtual servers that each points to two different pools:

    • Virtual Server 1 points to two different pools:

    • Virtual Server 2 points to two different pools:


And from SSL to SSQ, here's Synthecide. Stacey Q was lead singer of this mid-80s Berlin-sounding synth band before she went solo with the Madonna-sounding Two of Hearts. At that point, everyone decided to hate her and she was never heard from again.

Wednesday Dec 03, 2008

A Spring Framework in the OpenSSO Step

OpenSSO Community member Miquel has developed an extension based on Spring Security. Spring Security provides comprehensive security services for J2EE-based software applications with an emphasis on those built using the Spring Framework, an open source Java application framework.

In honor of our new extension, enjoy The Go-Betweens Spring Rain.

Tuesday Dec 02, 2008

Fedlet Logging and Loggins' Footloose

The Fedlet is a small footprint SAMLv2 JAR that can be deployed with a service provider application. It handles only SAMLv2 identity provider initiated POST profiles. The application in which it is embedded can then consume a SAML assertion to identify the user and identity attributes. The Fedlet uses your installed JDK to log its authentication access and errors (single sign-on successes, single log outs, etc.). By default, it uses the configuration defined at JAVA_HOME/jre/lib/ You can set the logging level to FINEST to see more details. For additional logging information, you can modify fedletSampleApp.jsp. More information on that modification can be found here. For debugging, the location of the file is defined in the OpenSSO file,

And when done logging, check out Kenny Loggins singing (and Kevin Bacon foot-syncing) in the music video for Footloose.

Wednesday Nov 26, 2008

Sweeping SAMLv2 Assertions from the 7th Floor

The following information was just put in the Sun OpenSSO Enterprise 8.0 Administration Guide but the new version won't be published until next week. Read the information here first. (There might be some changes to this entry based on answers to questions I have sent the engineer. I will update as necessary.) Requesting Identity Attributes via a SAMLv2 Assertion

The Assertion Query/Request profile specifies a means for requesting attributes (and the corresponding values) from a specific identity profile. A successful response is the return of an assertion containing the requested information. The identity provider acting as the attribute authority uses the com.sun.identity.saml2.plugins.AttributeAuthorityMapper to process queries. This default implementation uses the attribute map table configured in the identity provider's extended metadata; this table maps the requested SAMLv2 attributes to the user profile attributes in the identity data store. (If an attribute map is not configured, no attributes will be returned.)

To set OpenSSO to use a customized attribute mapper implementation, modify the values of the default_attributeAuthorityMapper and the x509Subject_attributeAuthorityMapper properties in the extended metadata of the provider defined as the attribute authority. The default_attributeAuthorityMapper value is used for a standard attribute queries and the x509Subject_attributeAuthorityMapper value is used for attribute queries with an X509 subject. The X509 mapper maps an X509 subject to a user by searching the identity data store for a specified attribute. (The specified attribute is defined as the value of the x509SubjectDataStoreAttrName property in the identity provider extended metadata of the attribute authority.) If the user has the specified attribute and the attribute's value is the same as that of the X509 subject in the attribute query, the user will be used.

Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the providers acting as the attribute requester and the attribute authority is configured.

  • To send an attribute query from the requester use the method of com.sun.identity.saml2.profile.AttributeQueryUtil.

    public static Response sendAttributeQuery(
    AttributeQuery attrQuery,
    String attrAuthorityEntityID,
    String realm,
    String attrQueryProfile,
    String attrProfile, String binding)
    throws SAML2Exception;
  • To construct an AttributeQuery object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\*.

Requesting a Cached SAMLv2 Assertion

The Assertion Query/Request profile specifies a means for requesting existing assertions using a unique identifier. The requester initiates the profile by sending an assertion request, referenced by the identifier, to a SAMLv2 authority. The SAMLv2 authority processes the request, checks the assertion cache for the identifier, and issues a response to the requester.

NOTE - In the metadata file of the identity provider acting as the SAMLv2 authority, add the following attribute to enable it to store assertions generated in the single sign-on, authentication query or attribute query process.

<IDPSSOConfig metaAlias="/idp">
<Attribute name="assertionCacheEnabled">

com.sun.identity.saml2.plugins.AssertionIDRequestMapper is the default implementation used to process the assertion request. To define a customized mapper, change the value of the assertionIDRequestMapper property in the extended metadata of the provider acting as SAMLv2 attribute authority or authentication authority.

  • To send a request for an assertion from a provider use either of the methods of com.sun.identity.saml2.profile.AssertionIDRequestUtil as below.
    public static Response sendAssertionIDRequest(
    AssertionIDRequest assertionIDRequest,
    String samlAuthorityEntityID,
    String role,
    String realm,
    String binding)
    throws SAML2Exception;
    public static Assertion sendAssertionIDRequestURI(
    String assertionID,
    String samlAuthorityEntityID,
    String role,
    String realm)
    throws SAML2Exception;
  • To construct an assertion request object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\* .

If SOAP binding is used, signing is required so the Signing Certificate Alias attribute of the service provider, identity provider, attribute authority and authentication authority metadata must be configured. In order to implement URI binding, you must write a custom mapper so that authenticateRequesterURI will not throw an exception.

Requesting SAMLv2 Authentication Context Information

A SAMLv2 assertion contains information regarding the context of a principal's authentication. The requesting party may require this additional information (for example, the authenticating technology or protocol used) in order to assess the level of confidence they can place in the assertion. To retrieve authentication context information, the service provider issues a query to the authentication authority.

Only SOAP binding is supported for this request And signing is required so make sure the Signing Certificate Alias attribute of the service provider and the authentication authority is configured.

To Configure for Authentication Context Query
  1. Create and load the metadata for the service provider.
  2. Create the metadata for the identity provider using ssoadm and specifying the following additional options.
    • -C Defines the meta Alias for the hosted authentication authority to be created. The format must be realm name/identifier.
    • -D Defines the authentication authority signing certificate alias.
    • -E Defines the authentication authority encryption certificate alias.

    For example:
    ssoadm create-metadata-templ -u amadmin -f /tmp/pw -m /home/user1/tmp/mm -x /home/usr1/tmp/xx -s /idp -a test -r test -C /authna -D test2 -E test2 -y
  3. Add the following attribute to the identity provider metadata file just created. This allows the identity provider to store assertions generated during the SAMLv2 single sign-on process.
    <IDPSSOConfig metaAlias="/idp">
    <Attribute name="assertionCacheEnabled">
  4. Configure for SAMLv2 single sign-on.
  5. Do either of the following:
    • To send an authentication query from the service provider use the com.sun.identity.saml2.profile.AuthnQueryUtil method.
      public static Response sendAuthnQuery( AuthnQuery authnQuery, String authnAuthorityEntityID, String realm, String binding) throws SAML2Exception;
    • To construct an AuthnQuery object, use com.sun.identity.saml2.assertion.\* and com.sun.identity.saml2.protocol.\*.

Mapping SAMLv2 Name Identifiers

The NameID Mapping Protocol allows a service provider that shares an identifier for a principal with an identity provider to obtain a name identifier for said principal in another format or that is in another federation name space (for example, is shared between the identity provider and another service provider). The requester initiates the profile by sending a NameIDMappingRequest message to the identity provider. After processing the request, the identity provider issues a NameIdMappingResponse message to the requester.

Only SOAP binding is supported. Signing is required so make sure the Signing Certificate Alias attribute of the identity provider and the service provider is configured.

To send a NameIDMappingRequest message from the service provider, use the method of the com.sun.identity.saml2.profile.NameIDMapping.

public static NameIDMappingResponse initiateNameIDMappingRequest( Object session,
String realm,
String spEntityID,
String idpEntityID,
String targetSPEntityID,
String targetNameIDFormat,
Map paramsMap) throws SAML2Exception;

And now that we are finished sweeping the floor, how about some dancing on the floor? Here's a home-made video to Paul Nicholas' number 7 hit from 1977, Heaven on the 7th Floor.

Thursday Sep 25, 2008

Are You Ready for OpenSSO Deployment 1?

Hi all. I'm still around but haven't had the time to blog as regularly as I'd (and hopefully you'd) like. Come November after the release of OpenSSO Enterprise 8.0, I will have more blog entries so stay tuned.

In the meantime, here is the Early Access edition of the Sun OpenSSO Enterprise 8.0 Deployment 1: Single Sign-on with Load Balancing and Failover. The book contains the procedures to implement, configure and test a full OpenSSO deployment for the purpose of single sign-on.

See comments below for UPDATES since this posting.

Key features of Deployment 1 include:
  • Installing and configuring Directory Server as a user data store.
  • Installing J2EE and web policy agents on protected resources.
  • Installing and configuring OpenSSO instances to run as a non-root user.
  • Configuring load balancers for session failover and high performance.
  • Configuring the deployment for system failover, ensuring that when one instance of OpenSSO Enterprise goes down, requests are redirected to the second instance.
  • Configuring components (including OpenSSO and Directory Server, the Distributed Authentication User Interface, and policy agents) as redundant to achieve high availability.
  • Configuring for Secure Sockets Layer (SSL) communications to the OpenSSO load balancer, to the Distributed Authentication User Interface load balancer, and to the Directory Server load balancer.
So check it out. You can also see the complete set of Early Access documentation for OpenSSO Enterprise 8.0. Now is the time to air your thoughts.

Thanks to Sun engineer Anant for his work on the book. Because of it, this book is an invaluable tool for understanding and keystroking an OpenSSO deployment.

And whether you are ready or not, Bucks Fizz certainly is. Are You Ready is the title song of their second album. Not sure if it's Jay or Cheryl wearing the diaper but it's quite an 80s sight!

Wednesday Aug 27, 2008

Change the Fedlet's Preferred IDP with John Waite

In order to change the preferred identity provider configured for a Fedlet, you can either remove the identity provider discovery cookie from the browser, or choose another identity provider to perform a single sign-on interaction. Following the latter, the identity provider is then set as the preferred identity provider.

Now here's the original MTV video (with attempted suicide and all) for Change, the hit single from former Babys front man, John Waite.

Change was a WLIR Screamer of the Week before they realized Waite wasn't new wave.

I'm in huge writing mode for the upcoming release of OpenSSO so please forgive for the relative dearth of posts. You're gonna love the books though!



« July 2016