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!

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 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.

Saturday Aug 23, 2008

Duffy, Lulu and Sub Realm Policy Administration in OpenSSO

Let's assume you have a top level realm named /opensso (because everybody has at one point). Under opensso create a sub realm called test. In the test sub realm, create a new user named usr1. Now create a new group, grp1, and assign read and write privileges for policy data to grp1 and assign usr1 to grp1.

Log in to the test sub realm using the URL http://fdqn:port/opensso/UI/Login?realm=test and the name and password for usr1. The administration pages for the sub realm are displayed in order to manage its policy data. If you use the URL http://fdqn:port/opensso/UI/Login, the user's page is displayed in order to manage the user profile. This insures the following:

  • usr1 will not have permission to manage policy data of the parent realm (opensso or any peer sub realms.
  • usr1 will have permissions to manage policy data of the test sub realm and any realms created beneath it.

Now, let's take the Duffy/Lulu taste test. First view the video for Mercy as performed by Duffy in 2008.

Now compare the voice you just heard to that of Lulu singing The Boat That I Row in 1968. Pretty close and forty years earlier.

Friday Aug 08, 2008

HELP! Review OpenSSO During Early Access

Sun is now soliciting feedback regarding the Early Access download (Express Build 5) of the OpenSSO software. Here's the official marketing shpiel:

The OpenSSO Project is soliciting feedback on their Early Access Build -- OpenSSO Express Build 5. With the release of this build, community members now have the opportunity to participate in the Early Access (EA) program for Sun's next commercial offering. Review the Early Access documentation and hammer away at Express Build 5! Send your EA feedback to so we can make the product perfect. Thanks in advance!

Now here's my shpiel - or should I say the Beatles shpiel in my stead:

But who would embed the Beatles HELP without also embedding the Bananarama version featuring Lananeeneenoonoo (or Dawn French, Jennifer Saunders and Kathy Burke).

And they did it all for others.

Just like all of us. Thanks.



« July 2016