Thursday Jun 12, 2008

What's Up, Doc? Early Access Docs!

We've just added a page to the OpenSSO site that contains links to some of the documentation now being written internally for the productized release of OpenSSO, Sun Federated Access Manager 8.0. These early access documents might contain information and procedures that have not yet been reviewed or tested. In fact, if you find something that doesn't sit right, shoot me an email or comment below and the writing team will look into it.

Click through to the Early Access Documents Page and start federatin'. The page will open in a new window because you know you want to see the credits of Peter Bogdanovich's 1972 film What's Up, Doc? with Barbra Streisand and Ryan O'Neal doing it to Cole Porter's You're the Top.

Monday Jun 09, 2008

Undeploying the Fedlet with Some Light from Jens Lekman

When undeploying fedlet.war (which you might've deployed for demonstration purposes), do the following:

  1. Undeploy the fedlet.war using your web container tools.
  2. Using the command line on the service provider side, delete the fedlet directory that was created during deployment.
  3. Using the OpenSSO console on the identity provider side, remove the entries for the identity provider, service provider, and circle of trust entries that were created under the Federation tab.
  4. Restart the web container on both the identity provider and service provider machines.

And now enjoy some light from Jens Lekman (who canceled his March 27, 2008 concert at the Gothic Theatre in Englewood because of a snowstorm in Seattle - leaving the Mile High City high and Lekman-dry).

Wednesday Jun 04, 2008

Common Tasks and Common People

Here is how I setup two instances of Federated Access Manager as SAMLv2 providers using the Common Tasks work flow options. I have Glassfish running as the web container on two different machines. On each machine, I deployed the fam.war (the productized version of OpenSSO). The first instance of Federated Access Manager on the machine at is now configured as a hosted identity provider using the following procedure.

  1. Launch the FAM console at and log in as amadmin.
  2. Select Create Hosted Identity Provider under the Common Tasks tab to configure the instance as a SAMLv2 identity provider.
    Select the test key for both signing and encryption, name the circle of trust (for example, idpcot), and keep the default values for the other fields.
  3. Click Configure.
  4. Select Finish to end the task.
    Don't configure anything else on this instance YET.

This instance of Federated Access Manager is now configured as a SAMLv2 identity provider.

The second instance of Federated Access Manager on the machine at is now configured as a hosted service provider, and to communicate with the remote identity provider. P>

  1. Launch the FAM console at and log in as amadmin.
  2. Select Create Hosted Service Provider under the Common Tasks tab to configure the instance as a SAMLv2 service provider.
    Select the test key for both signing and encryption, name the circle of trust (for example, spcot), and keep the default values for the other fields.
  3. Click Configure.
  4. Select the Register Remote Identity Provider task from the resulting window (or from under the Common Tasks tab) to configure the service provider for communication with the previously-configured identity provider.
    Enter to dynamically load the identity provider meta data, select the test key for both signing and encryption, and choose the circle of trust previously configured for the hosted service provider.
    See here for an explanation of directories if this URL leads to some confusion.
  5. Click Configure.
  6. Select Finish to end the task.

Finally, to finish the federation configuration, return to the identity provider console ( and log in as amadmin. Select Register Remote Service Provider and enter to dynamically load the remote service provider meta data. Also, select the test key for both signing and encryption, and choose the circle of trust previously configured for the hosted identity provider. After configuration, we can now test the connectivity between the instances.

Using the identity provider console (as we are still logged in), select Test Federation Connectivity. My first attempt at this failed on Account Linking. Not having any idea why, I pinged our trusty engineers and found that, because I was using two instances of Federated Access Manager on different machines in the same domain, iPlanetDirectoryPro (the name of Federated Access Manager cookie that carries the SSOToken) was being overwritten so I had to change the cookie name (on one instance only) under the Configuration -> Sites and Servers tabs. (If you need to do this, restart your web container after making the change.)

  1. Click Inheritance Settings.
  2. Deselect the Cookie Name checkbox and Save.
  3. Modify the Cookie Name value to, for example, idpcookie.
  4. Click Save.

So I ran the test again and this is what I saw. (I used the demo user, configured during deployment of Federated Access Manager.)

  1. Select Test Federation Connectivity.
  2. Select the circle of trust that contains the providers you are testing.
  3. Select the providers you are testing.
  4. Click Start Test.
  5. Click OK to begin.
  6. demo and the password changeit.
  7. demo and the password changeit.
  8. Behind the scenes, the two user accounts will be linked.
  9. Behind the scenes, the user will be logged out of the service provider.
  10. Behind the scenes, the user will be logged in to the service provider without provider credentials.
  11. Behind the scenes, the two user accounts will be unlinked (delinked?).

Now that the federation has been proven successful I'm moving on to the Fedlet. In the meantime, enjoy William Shatner's cover of Common People.

And here's the original from Pulp.

Friday May 30, 2008

A Family of fam Directories

In the midst of deploying, configuring and launching Federated Access Manager to learn about the Fedlet, I got a bit confused about the different directories that are created during the process. The first time I come into contact with a fam directory is when I download When the file is unzipped, everything is put into the /fam directory on the same level on which the ZIP was downloaded. This directory contains fam.war which will be used to deploy Federated Access Manager as well as other adjunct pieces of Federated Access Manager. This directory is not used by Glassfish (my web container of choice) or Federated Access Manager, and should be exploded in a download directory of your choice.

The second fam directory rears it's head when I log into the Glassfish console to deploy fam.war. By default, Glassfish uses the name of the about-to-be-deployed WAR file (without the file extension .war) as the value for its Application Name and Context Root attributes. The context root, which must start with a forward slash (/) and end with a string, identifies a unique, base directory for a web application deployed in a J2EE web container. Glassfish creates this directory in /glassfish/domains/domain_name/applications/j2ee-modules/, and the URL for the deployed web application will include this context root; in this example, http://host_machine:port/fam. The J2EE web container then uses this URL to determine which web application services an incoming request. The context root is stored in sun-web.xml, and the value can be manually modified while deploying the WAR if you want to use another name besides that ubiquitous fam.

The final fam directory is the default value for the configuration directory created after the WAR is deployed and the Federated Access Manager Configurator is launched. This value can be changed to any directory to which the web container can write - and I would do that to remain sane. In the course of configuration, a tree is created under the configuration directory that contains the bootstrap file, a sub config directory, an opends directory, and other files.

So there you have it: three directories with different purposes that make Federated Access Manager family friendly. Now join hands with a different Family, the cast of Dreamgirls.

Thursday May 29, 2008

Altering Technical Overview Images

The following images need to be reviewed. They will be in the Technical Overview for Federated Access Manager 8.0. Please check for accuracy and simplicity. Feel free to remove extraneous boxes, code, etc. Sorry to those external to Sun's intranet; the links are internal only (although if you can find the blog entry where I sent out the Technical Overview for review you can look at the PDF or if you go to the Engineering Documents page on you can find the originals).

The following image illustrates the internal architecture of Federated Access Manager.

The following image illustrated the authentication and authorization interactions.

The following image illustrates the communication between authentication service components

The following image illustrates the components of the Policy Service.

The following image illustrates the components of the Session Service.

The following image illustrates the components of the Logging Service.

The following image illustrates the components of Federation Services.

The following image illustrates the interactions of Web Services Security.

The following image illustrates the interactions of Identity Services.

And while we are altering images, here is Altered Images and Don't Talk to Me About Love.

Wednesday May 21, 2008

You Gotta Get an Administrative User - and a Gimmick

Following are the four users created by OpenSSO in the embedded data store during an installation/configuration:

  • puser is a proxy user used for all queries made to the embedded data store. It benefits from a configured proxy user ACI and, therefore, can take on any user's privileges (for example, the organization administrator or an end user) and perform actions on behalf of that user when necessary. It maintains an open connection through which all queries are passed (retrieval of service configurations, organization information, etc.). The puser password is always encrypted.
  • dsameuser is used for binding to the embedded data store when the Client SDK performs operations that are not linked to a particular user (for example, retrieving service configuration information). puser performs these operations on behalf of dsameuser, but a bind must first validate the dsameuser credentials. dsameuser should have the permissions to add, delete, modify, and search the data store. secret12 is the default password.
  • amldapuser is used to bind to and search supported LDAP servers during LDAP and Membership authentication. The Authentication Service binds to the server as amldapuser in order to search for a user to match the login identifier passed by the user. It is also used internally for configuring policy. secret123 is the default password.
  • amadmin is the administrative user for OpenSSO. admin123 is the default password.

And here's the gimmick: Faith Dane as Mazeppa, Roxanne Arlen as Electra, Betty Bruce as Tessie, and the luminescent Natalie Wood sitting through it all as Louise in Gypsy.

Monday May 19, 2008

A Secret Agent Property and a Secret Agent Man

Notwithstanding the break neck speed at which the blog on new policy agent properties was posted, I found another new property specific to the J2EE agent.


This property is used when the agent is installed behind a proxy or load balancer. Often time the client IP address returned by request.getRemoteAddr() is that of the proxy or load balancer - not the real client IP. The proxy or load balancer may set the real client IP in an X-Forward-IP header so, setting the property com.sun.identity.agents.config.client.ip.header equal to X-Forward-IP will make the agent retrieve the real client IP address from this header to use in the policy evaluation.

And from a secret agent property to a Secret Agent - here's the smash hit theme from the television series Secret Agent called Secret Agent Man as interpreted by Johnny Rivers.

Who knew he played the guitar? UPDATED 5/21/08

Active Directory Attributes and A-HA

Out-of-the-box, OpenSSO defines a set of objectclasses and attributes that are required to be a part of your directory schema if you want to manage the user entries using the OpenSSO console. If the directory you are trying to access does not have the predefined objectclasses and attributes, any attempted access involving the missing properties will fail. For example, when you create a user using the OpenSSO console, the console writes to the directory the predefined objectclasses and attributes for the user. If the directory is not configured with the same set of user objectclasses and attributes, the user create operation will fail.

When configuring Microsoft Active Directory to work with OpenSSO, you have to map the predefined properties to properties defined in your instance of Active Directory; this is attribute mapping. Following are the attributes that need to be defined when adding Active Directory as a data store to a realm. The configuration will allow you to list users and groups. It will also allow you to perform some user operations. The values assume a freshly installed Active Directory to which no attribute or schema changes have yet been made.

Still waiting for some email to verify some of the newer attributes. Will update when I receive them.

  • LDAP Server enter the host machine name and port number of the instance of Active Directory to which you are connecting. For example,
  • LDAP Bind DN by default, CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Bind Password enter the password for CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Bind Password (confirm) confirm the password for CN=Administrator,CN=Users,dc=sun,dc=com
  • LDAP Organization DN enter the distinguished name (DN), defined in Active Directory, of the organization to which this data store will map; this becomes the base DN for all operations performed in this data store
  • LDAP SSL select if the directory is configured in SSL mode
  • LDAP Connection Pool Minimum Size specify the initial number of connections allowed in the connection pool; using the connection pool avoids creating a new connection every time
  • LDAP Connection Pool Maximum Size specify the maximum number of connections allowed
  • Maximum Results Returned from Search specify the maximum number of results to return when searching; this figure should be based on the size of your LDAP organization and cannot exceed the ns size limit configured on the directory side
  • Search Timeout specify the maximum time in seconds to wait for results from a search operation
  • LDAP Follows Referral select to specify whether or not referrals to other LDAP servers are automatically followed
  • LDAPv3 Repository Plug-in Class Name specify the path to the implemented class for Active Directory; by default, com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo
  • Attribute Name Mapping map any OpenSSO attributes to those in Active Directory; by default:

    • employeeNumber=distinguishedName
    • iplanet-am-user-alias-list=objectGUID
    • mail=userPrincipalName
    • portalAddress=sAMAccountName
    • telephonenumber=displayName
    • uid=sAMAccountName
  • LDAPv3 Plug-in Supported Types and Operations no changes needed
  • LDAPv3 Plug-in Search Scope select the range of any plug-in searches
  • LDAP Users Search Attribute specify the attribute used to search; by default, uid
  • LDAP Users Search Filter specify which entries the search will return; by default, only those entries that contain objectclass=person
  • LDAP User Object Class define the objectclasses added to a user's attribute list when the user is created; by default:

    • organizationalPerson
    • person
    • sunFederationManagerDataStore
    • sunFMSAML2NameIdentifier
    • sunIdentityServerLibertyPPService
    • top
    • User

    (objectclasses defined must actually exist in Active Directory or be mapped to one that exists otherwise you will get an objectclass violation)
  • LDAP User Attributes define the definitive list of attributes associated with a user entry; the attribute will not be sent or read if it is not on this list which, by default:

    • employeeNumber
    • objectClass
    • sAMAccountName
    • userpassword
    • mail
    • distinguishedName
    • userPrincipalname
    • objectGUID
    • sAMAccountType
    • name
    • displayName

    (if there is the slightest possibility that the user entry will contain an attribute include it here; on the other hand, if the attribute is not defined in Active Directory, do not enter it)
  • Create User Attribute Mapping
  • Attribute Name of User Status check the defined attribute to see if user is active or inactive; by default, userAccountControl
  • User Status Active Value
  • User Status Inactive Value
  • LDAP Groups Search Attribute by default, cn is the attribute used to construct the group's DN and search filter
  • LDAP Groups Search Filter by default, the search filter will return only those entries that contain objectclass=group
  • LDAP Groups Container Naming Attribute define the naming attribute for a group container if the groups reside in a container; by default, cn
  • LDAP Groups Container Value users (the value for the group container.)
  • LDAP Groups Object Class defines the objectclasses that will be added to a group when it is created; by default:

    • Group
    • top
  • LDAP Groups Attributes defines the definitive list of attributes associated with a groups entry; the attribute will not be sent or read if it is not on this list;

    • cn
    • distinguishedName
    • dn
    • member
    • name
    • objectCategory
    • objectclass
    • sAMAccountName
    • sAMAccountType

    (if there is the slightest possibility that the group entry will contain an attribute include it here; on the other hand, if the attribute is not defined in Active Directory, do not enter it)

  • Attribute Name for Group Membership specify the attribute in the user entry that contains the values that define the groups to which the entry belongs; generally, memberOf
  • Attribute Name of Unique Member specify the attribute in the groups entry that contains the DN of each member; by default, member
  • Attribute Name of Group Member URL specify the attribute in the groups entry whose value is an LDAP URL which resolves to the members belonging to it; by default, memberUrl
  • LDAP People Container Naming Attribute specify the attribute in a user entry of the people container in which the users reside, if applicable; leave blank if they don't reside in a people container
  • LDAP People Container Value by default, users
  • Identity Types That Can Be Authenticated
  • Authentication Naming Attribute by default, uid
  • Persistent Search Base DN specify the base DN to use for persistent searches; this needs to be the root suffix of your Active Directory instance
  • Persistent Search Filter specify which entries the search will return; by default, only those entries that contain objectclass=\*
  • Persistent Search Scope select the range of any persistent searches
  • Persistent Search Maximum Idle Time Before Restart specify the time in minutes before restarting an idle persistent search
  • Maximum Number of Retries After Error Codes specify the maximum number of times that a persistent search can be retried if it encounters the specified error codes; by default, 3
  • The Delay Time Between Retries specify the time in milliseconds to wait before each retry; by default, 1000
  • LDAPException Error Codes to Retry On specify the error codes that will initiate a retry on a persistent search operation; only applicable for persistent searches
  • Caching select enable
  • Maximum Age of Cached Items specify the oldest (in seconds) a cache item can be before it is removed; by default, 600
  • Maximum Size of the Cache specify the maximum size of the cache; by default, 10240

Now let's move on from the Active Directory attributes (ADA) to A-HA and my favoritest song by them. Oh, the nights I danced to this one!

Friday May 16, 2008

A Realm is a Bin for Data When You Need to Store

When you deploy OpenSSO in your favorite web container, opensso is configured as the root realm. A realm (under the Access Control tab) is a group of authentication properties and authorization policies that can be associated with a user or group of users, or a collection of protected resources. For example, you can create a realm that groups all servers and services accessed by employees in one region. Within that regional realm, you can group all servers and services accessed regularly by employees in a specific division, such as Human Resources. And even more fine-grained, you can add constraints that allow users to access a particular service from Monday through Friday, 9:00 a.m. to 5:00 p.m.

The root realm is where you configure user (identity) data stores, manage policies and create authentication chains globally. A Realm Administrator can do all these operations in the root realm while the Policy Administrator can only create and manage policies. Under the root realm, you configure sub-realms. Sub-realms enable the following scenarios.
  1. You need an administrator who can create policies for a sub-set of resources only. For example, let's assume you want an administrator to create policies for resources that reside at

    1. Create a subrealm under opensso named paycheck.
    2. Under the opensso root realm, create a policy referral with the Resource Name defined as
    3. Under the paycheck sub-realm, create a group under Subjects called PaycheckAdmin and select the appropriate privilege (Read and write access only for policy properties) under Privileges.
    4. Modify the appropriate user profile and policy under the sub-realm to reflect this new privilege and the user can then login to the sub-realm and create policies for the defined resources. The sub-realm, in this case, is mainly for the policy administrator to manage the policies for the configured resources.

    By default, paycheck will have the same data store and authentication chains as opensso, its parent realm. If configurations change in the parent realm, a corresponding change in the sub-realm policy might be needed.
  2. You need each sub-realm to have its own set of data stores (identities), authentication chains and policy administrators. Ideally there would be nothing in common between the root and the sub-realm except for the referral policy created under the root realm to delegate all, or a subset of, resources to the sub-realm. With this scenario, users would be created within, and authenticate to, their sub-realm. Agents would also have to be configured to redirect user authentication to the sub-realm.

Regarding performance, the most resource-consuming component of the realm architecture is the persistent searches done using the one data store in the first scenario. This is not really an issue in the second as the searches go to different directories. A guess on the number of sub-realms that can be supported would be about 100 for the first scenario and about 50 for the second.

And although a realm is a bin for data when you need to store, remember that a dream is a wish you heart makes when you're fast asleep. Sing along below but not too loud if you're in an office with the door open.

Oy, did I really just post a music video from Cinderella? Should I have posted something from La Cenerentola to show how couth I am? Maybe but unfortunately I don't understand Italian and thus couldn't find a cute title for this entry a la Rossini.

Friday May 02, 2008

Policy Agent Configuration with Agent 99

When configuring a 3.0 policy agent, you can choose either Local Configuration or Centralized Configuration. (You can also change from centralized to local after configuration using the console.) If Local Configuration is chosen, the properties will be stored in a properties file on the agent machine. You cannot use the console to edit locally configured properties. With Centralized Configuration, 3.0 policy agent properties can be modified using the console or the famadm command line interface.

To set the configuration on the command line, use famadm to set the new property (see table below) com.sun.identity.agents.config.repository.location with a value equal to local. (The default value is centralized.)

The console uses human-readable property labels rather than the programmatic property names; for example, com.sun.identity.agents.config.login.url is displayed as FAM Login URL in the console. When using famadm for configuration, you need to use the 3.0 property names. For version 3.0 web agents, the property names have been changed; for J2EE agents, the property names for 2.2 and 3.0 are the same. Following is a mapping of the old and new web agent properties.

Old Name New Name com.sun.identity.agents.config.naming.url com.sun.identity.agents.config.log.level com.sun.identity.agents.config.local.logfile com.sun.identity.agents.config.username com.sun.identity.agents.config.password com.sun.identity.agents.config.sslcert.dir com.sun.identity.agents.config.certdb.prefix com.sun.identity.agents.config.certdb.password com.sun.identity.agents.config.certificate.alias com.sun.identity.agents.config.receive.timeout com.sun.identity.agents.config.connect.timeout com.sun.identity.agents.config.tcp.nodelay.enable com.sun.identity.agents.config.login.url com.sun.identity.agents.config.local.log.rotate com.sun.identity.agents.config.local.log.size com.sun.identity.agents.config.audit.accesstype com.sun.identity.agents.config.remote.logfile com.sun.identity.agents.config.deny.access.log.failure com.sun.identity.agents.config.notification.enable com.sun.identity.agents.config.policy.cache.polling.interval com.sun.identity.agents.config.sso.cache.polling.interval com.sun.identity.agents.config.userid.param com.sun.identity.agents.config.userid.param.type com.sun.identity.agents.config.profile.attribute.fetch.mode com.sun.identity.agents.config.profile.attribute.mapping com.sun.identity.agents.config.session.attribute.fetch.mode com.sun.identity.agents.config.session.attribute.mapping com.sun.identity.agents.config.response.attribute.fetch.mode com.sun.identity.agents.config.response.attribute.mapping com.sun.identity.agents.config.load.balancer.enable com.sun.identity.agents.config.agenturi.prefix com.sun.identity.agents.config.locale com.sun.identity.agents.config.sso.only com.sun.identity.agents.config.access.denied.url com.sun.identity.agents.config.fqdn.check.enable com.sun.identity.agents.config.fqdn.default com.sun.identity.agents.config.fqdn.mapping com.sun.identity.agents.config.cookie.reset.enable com.sun.identity.agents.config.cookie.reset com.sun.identity.agents.config.cookie.domain com.sun.identity.agents.config.anonymous.user.enable com.sun.identity.agents.config.notenforced.url com.sun.identity.agents.config.notenforced.url.invert com.sun.identity.agents.config.notenforced.ip com.sun.identity.agents.config.notenforced.url.attributes.enable com.sun.identity.agents.config.postdata.preserve.enable com.sun.identity.agents.config.postcache.entry.lifetime com.sun.identity.agents.config.client.ip.validation.enable com.sun.identity.agents.config.profile.attribute.cookie.prefix com.sun.identity.agents.config.profile.attribute.cookie.maxage com.sun.identity.agents.config.cdsso.enable com.sun.identity.agents.config.cdsso.cdcservlet.url com.sun.identity.agents.config.logout.url com.sun.identity.agents.config.logout.cookie.reset com.sun.identity.agents.config.fetch.from.root.resource com.sun.identity.agents.config.convert.mbyte.enable com.sun.identity.agents.config.encode.url.special.chars.enable com.sun.identity.agents.config.override.protocol com.sun.identity.agents.config.override.port com.sun.identity.agents.config.override.notification.url com.sun.identity.agents.config.connection.timeout com.sun.identity.agents.config.ignore.server.check com.sun.identity.agents.config.poll.primary.server com.sun.identity.agents.config.ignore.preferred.naming.url com.sun.identity.agents.config.iis.auth.type com.sun.identity.agents.config.replaypasswd.key com.sun.identity.agents.config.iis.filter.priority com.sun.identity.agents.config.iis.owa.enable com.sun.identity.agents.config.iis.owa.enable.change.protocol com.sun.identity.agents.config.iis.owa.enable.session.timeout.url
NEW com.sun.identity.agents.config.repository.location
NEW com.sun.identity.agents.config.freeformproperties
NEW com.sun.identity.agents.config.polling.interval
NEW com.sun.identity.agents.config.cleanup.interval

I'll see if I can find mappings between the new names and the console labels and let you know when I do. They ain't always easy to figure out. But, wait, we're not done with agents yet. Here's, what I assume is, Barbara Feldon's only foray into song. It's called 99 and was released when she was on top of her game as Agent 99 in the 1960s television series, Get Smart.

Monday Apr 28, 2008

Sticky Cookies and Sticky Fingers

A load balancer deployed with OpenSSO must support sticky sessions. A sticky session specifies that once a session is created by a specific OpenSSO instance subsequent requests from the user will be routed to that same instance to preserve session information. If you have a deployment with a load balancer between 2 instances of OpenSSO, you can configure the load balancer for cookie stickiness by defining the value of the property to the name of the cookie; amlbcookie is the default name of the sticky cookie. When cookie stickiness is enabled, you will get better performance from OpenSSO by avoiding back channel communications, and the OpenSSO console will work properly behind the load balancer. More information on cookies and sticky sessions can be found in the official Access Manager 7.1 documentation. And since sticky cookies give you sticky fingers, here's a live video of The Rolling Stones singing a song (which shall remain nameless in this entry) from their 1971 LP, Sticky Fingers.

Thursday Apr 24, 2008

Centralized Agent Configuration and Eurovision

Policy agents function based on a set of configuration properties. Previously, these properties were stored in the file that resides on the same machine as the agent. With centralized agent configuration, OpenSSO moves most of the agent configuration properties to the configuration data store.

Agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Agent configuration data is now relegated to the following:

  1.\* contains bootstrap data and is stored on the agent machine. This file indicates the location from where the configuration properties need to be retrieved. It is used by agents profiles configured locally or centrally.
  2.\* contains local configuration data and is stored on the agent machine. It is only used by agent profiles configured locally.
  3. The configuration data store holds the remainder of the agent configuration data.

With agent configuration centralized, an administrator is able to manage multiple agent configurations from the OpenSSO console. Most of the agent properties are hot swappable. (Properties can be modified without rebooting the underlying agent web container.) Additionally, notification of the agent when configuration data changes and polling by the agent for configuration changes is enabled. Agents can also receive notifications of session and policy changes.

NOTE: The configuration change notification does not contain the new data; it is just a ping that, when received, tells the agent to make a call to OpenSSO and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.

The figure below illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.

Now that you've got an idea about centralized agent configuration in OpenSSO, how about checking out the Icelandic entry in Eurovision 2008. Here's Euroband singing This Is My Life.

\*UPDATE: Thanks to Sean for the properties files update.

Tuesday Apr 22, 2008

The FAM Technical Overview and the Shuttered Palace

I've finished the first draft of the first two chapters of the Sun Federated Access Manager 8.0 Technical Overview. Download a PDF, lock yourself in a room, read it, and feel free to leave me your comments.

And while shuttered in your room, watch Ellen Foley (of Meat Loaf/Paradise by The Dashboard Light, Hair and Night Court fame) in The Shuttered Palace from her 1982 LP, The Spirit of St. Louis featuring members of The Clash.

Monday Apr 21, 2008

CommunityOne, Second LIfe and Three Dog Night

Just a few reminders to start your Monday morning:
  1. CommunityOne is coming on May 5, 2008. This FREE open-source conference is piggy-fronted on the Monday before JavaOne begins. There are many, many workshops and sessions to choose from. Those that might interest users of OpenSSO include:

    A PDF of the full CommunityOne schedule can be downloaded here.
  2. Second Life is a three-dimensional virtual world. Sun Microsystems now has a few islands in Second Life and are planning a big employee party on April 29. (Sorry non-Sun employees. The party though is only on one of Sun's islands; the other islands are open to all.) I'm not a gamer so I don't usually play around with these types of things but I am attending the employee party. I've already created my avatar - which took forever to finish and looks as much like me as a cartoon character can. Sun employees only can check out the internal web site but everyone can follow along at the external virtual worlds blog.
  3. And to turn this couplet into a triumverate, here's a video of Three Dog Night singing Out in the Country. Sad how relevant this song is today, almost forty years after it was initially written.

Wednesday Apr 16, 2008

Using the amunixd Daemon and Me

The current Access Manager 7.1 and the future Federated Access Manager (FAM) 8.0 (not OpenSSO as it does not bundle native platform binaries) can be configured to process authentication requests against Unix user IDs and passwords known to the Solaris or Linux system on which it is installed. The Unix Authentication module makes use of an authentication helper daemon, amunixd, which opens a socket to localhost:58946 in order to listen for Unix authentication requests. It is a separate process from the FAM process. At startup, this daemon listens on a port for configuration information.

Previously documented for Access Manager 7.1 incorrectly, this entry takes the information from the filed bug to rectify that faux-pas. The correct syntax for amunixd is:

amunixd -i #-of-addrs -a ipaddr-1 -a ipaddr-2 ... -a ipaddr-N

In an instance of Federated Access Manager deployed in a web container, amunixd can be found in any of the following directories:
  • /fam/tools/helpers/bin
  • /fam/tools/helpers/sparc
  • /fam/tools/helpers/x86
And now that you see the correct usage, you can use amunixd or, if you'd like to, use something else - as Bill Withers so eloquently sings in the video below.

Thursday Apr 10, 2008

The Policy Condition Timeout Value Makes Time for Spike Jones

The Timeout Value attribute of the Policy condition Authentication by Module Instance defines when the application (defined as the value of the Application Name attribute of the Policy condition Authentication by Module Instance) should force re-authentication.

CAUTION : The application name (app_name in session below) is a grouping of resources being protected. For example, all resources that constitute the paycheck application can be defined as paycheck. So, if the same app_name (in this case, paycheck) is used in two different policies with different Timeout Value values, the result is randomly picked up.

An authenticated user can lose access to a protected resource after a defined amount of time has passed (from the time of authentication). If the user attempts access after the time is up, the policy agent will force authentication again using the scheme configured in the Authentication by Module Instance condition. After successful authentication, the user will again be allowed access to the resource. Re-authentication will be required to access the protected resource, if idle, regardless of the session time limits. (If the Timeout Value is longer than the maximum session time, the user will not be affected by it but, if the session's idle timeout is reached, the session will timeout.)

For example, assume Application A and Application B are configured for single sign-on. Additionally:

  • Application A has a Timeout Value equal to 10 minutes
  • Application B has a Timeout Value equal to 60 minutes

A user successfully logs in to Application A and receives a session token. When the same user accesses Application B, no additional authentication is needed. But, after ten minutes of idle time, Application A requires re-authentication. A use cases for this attribute might be when user jdoe logs in to a protected application configured for re-authentication after 10 minutes of idle time (from the time of authentication set in the session). jdoe leaves the public computer with out closing the browser, and user jsmith arrives ten minutes after and attempts to access the resource again. The login page is displayed and jsmith must authenticate before access is permitted.

One thing to keep in mind is that this attribute value does not depend on the session time limit. For every time authentication is forced, the moduleAuthTime property in the session token is checked against the value of the Timeout Value condition in the policy. A typical session might look like this:

<Session sid="AQIC5wM2LY4Sfcy6UFgE25jdHKzJwphzxFrvqL1suAk/8aU=@AAJTSQACMDE=#" stype="user" cid="uid=amAdmin,ou=People,O=SUN\\\\ MICROSYSTEMS INC." cdomain="o=sun microsystems inc." maxtime="120" maxidle="30" maxcaching="3" timeidle="10" timeleft="6694" state="valid">
<Property name="CharSet" value="UTF-8"></Property>
<Property name="UserId" value="amAdmin"></Property>
<Property name="successURL" value="/amserver/console"></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="am.protected.policy.AppIdleTimesoutAt.app_name" value="1172883917924"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4SfczFsOZaE5/uQQtygnlHv1mJuFlOY3K4uUg=@AAJTSQACMDE=#"></Property>
<Property name="UserToken" value="amAdmin"></Property>
<Property name="loginURL" value="/amserver/UI/Login"></Property>
<Property name="IndexType" value="module_instance"></Property>
<Property name="Principals" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
<Property name="moduleAuthTime" value="LDAP+2007-03-03T01:04:17Z|mem+2007-03-03T01:06:39Z"></Property>
<Property name="" value="id=amadmin,ou=user,o=sun microsystems inc.,amsdkdn=uid=amadmin,ou=people,o=sun microsystems inc."></Property>
<Property name="amlbcookie" value="01"></Property>
<Property name="Organization" value="o=sun microsystems inc."></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="HostName" value=""></Property>
<Property name="Host" value=""></Property>
<Property name="UserProfile" value="Required"></Property>
<Property name="AMCtxId" value="4b21c5d982164fbe01"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="authInstant" value="2007-03-03T01:06:39Z"></Property>
<Property name="Principal" value="uid=amAdmin,ou=People,O=SUN MICROSYSTEMS INC."></Property>
The following properties in the session are relevant.
  • am.protected.policy.AppIdleTimesoutAt.app_name
  • moduleAuthTime

NOTE : The protecting policy agent should run in self policy decision cache mode and the property should be set to false.

I'm taking tomorrow off to spend the weekend in Yosemite. 65 years ago, Spike Jones and his City Slickers made a soundie that neatly sums up how I feel having three days off.

Monday Apr 07, 2008

Conquering LDAP Redeploy Errors By Using Them Up and Wearing 'Em Out

The lab machines reserved for us writers are none-too-current: hard drive size and RAM are not the correct specifications for deploying Glassfish, OpenSSO, and other agents/web services. Because of this I always have issues re-deploying a new OpenSSO WAR file successfully...until today (actually Friday but I'm writing this today).

When I undeploy the OpenSSO WAR, it leaves some processes running on Glassfish which don't allow for a new WAR to be deployed. (I've seen mainly LDAP and OpenDS errors.) I figured out that I can redeploy a new OpenSSO WAR if I have a new install of Glassfish - which puts the step where I have to jumpstart and wait for a new OS to be installed (and therefore wait for the lab guy to restart the DNS) in the trash. So follow this procedure to find the processes, kill them, uninstall Glassfish, and get it back up.

  1. Run jps at the command line.
    This is the command for discovering running Java processes.
  2. Kill any PELaunch processes you see using the kill -9 process-number command on the command line.
  3. Remove the glassfish directory.
  4. Start all over again using this blog entry.

Voila, I got the whole shebang up and running again. Not too pretty but it works.

And here is something else that works: a cover of (the late 70s dance group) Odyssey's excellent tune Use It Up and Wear It Out by early 90s disc jockeys Pat & Mick - as produced by PWL. Shake your body down!

Thursday Apr 03, 2008

Reviewing Implementing Federation and Watching I'm Gonna Be Strong

Between blog entries, I am writing the Sun Java System Federated Access Manager 8.0 Technical Overview. Aside from writing about new features, this book also includes updated material first written for Access Manager 7.1, the SAMLv2 Plugin for Federation Services and Federation Manager 7.0. Towards that lofty goal, I have finished a draft for the chapter entitled Implementing Federation. This chapter collects information regarding the federation protocol available in Federated Access Manager 8.0.

I've sent the chapter to internal Sun engineers for review but I also want to hear from the OpenSSO community. A PDF of this chapter is available for your perusal here. If you have any ideas on what might be missing, or comments on what is currently included please feel free to leave a comment or email me.

Since I'm gonna be strong when I read all these comments, here's Gene Pitney singing I'm Gonna Be Strong. This man has one of the best voices; I never tire of hearing the old records (yes, records) that I have of his.

Cyndi Lauper, one of the best female voices, covered I'm Gonna Be Strong when she was the lead singer of Blue Angel in 1980 (and then again on a solo album). Here's a clip of Cyndi singing the Barry Mann and Cynthia Weil classic with Blue Angel.

I also covered I'm Gonna Be Strong (a cappella, mind you) when I was performing songs and pithy comedy eons ago. I shall find that video tape and one day make this couplet a triplet. That should be scary!

Wednesday Apr 02, 2008

How to Configure PAL Portal and OpenSSO

In my travails around the 'net, I came upon this blog entry that explains how to configure PAL Portal for use with OpenSSO. Great that someone wrote this up but I had no idea what PAL Portal was so I found this blog entry (from the same Portal Application Laboratory blog) that explains what PAL Portal is and where to download it. Oh, cool. An open-source portal server. But what's Jetspeed2? Oh, cool. An open-source portal enterprise server.

Uh, can we get a few more layers on this architecture, please!


If you're not interested in getting OpenSSO to work with PAL Portal, you might be interested in this video by Grace Potter and the Nocturnals. It's the song Ah Mary.

Tuesday Apr 01, 2008

Setting Up Web Services Security, the Security Token Service and the Tokens

This procedure assumes that you already have an instance of the Glassfish Application Server installed. The following sections must be completed.

  1. Creating Glassfish Domains and Deploying OpenSSO WAR
  2. Deploying the Web Service Provider on Glassfish
  3. Configuring the WSP to Use the Security Token Service
  4. Configuring the Web Service Client (WSC) and the WSP to Use the Security Token Service
  5. Configuring the WSC to Use the Security Token Service

Creating Glassfish Domains and Deploying OpenSSO WAR
  1. Using Glassfish, create two domains - one named wsc and the other wsp.

    1. Create /tmp/passfile with following content:

    2. Create the domains using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

      ./asadmin create-domain --adminuser admin --passwordfile /tmp/passfile --portbase 7000 wsc

      ./asadmin create-domain --adminuser admin --passwordfile /tmp/passfile --portbase 9000 wsp
  2. Change to the GLASSFISH_INSTALL_DIR/domains/wsc/config/ directory and make the following changes to the domain.xml file.

    1. Change jvm-options from -client to -server.
    2. Change jvm-options from -Xmx512m to -Xmx1G.
  3. OPTIONAL: If OpenSSO has already been deployed and configured, remove the deployed WAR as follows:

    1. Undeploy the application using the Glassfish console.
    2. Delete the /opensso configuration directory.

      rm -rf /opensso
    3. Delete the /AccessManager directory.

      rm -rf /AccessManager
  4. Start the two domains using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin start-domain wsc
    ./asadmin start-domain wsp
  5. (Re)deploy the OpenSSO WAR in the wsc domain using the Glassfish console.

    Keep the default values and click OK.
  6. Launch the deployed OpenSSO web application from the Glassfish console and, when the configuration wizard is displayed, under Custom Configuration, select Create New Configuration.
  7. Use the following values to create the new configuration and click Create Configuration when finished.

    1. Enter a password for amadmin under the General settings, confirm it and click Next.
    2. Keep the default Server Settings values (or modify as necessary) and click Next.

      • Server URL - for example,
      • Cookie Domain - for example,
      • Platform Locale - for example, en_US
      • Configuration Directory - for example, /openssoconfig
    3. Keep the default Configuration Store values (or modify as necessary) and click Next.

      • Data Store Type - for example, Embedded (Open DS)
      • Port - for example, 50389
      • Encryption Key - as populated by configurator
      • Root Suffix - for example, dc=opensso,dc=java,dc=net
    4. Ensure that the Embedded radio button is selected as the default User Store Settings value and click Next.
    5. Ensure that the No radio button is selected as the default Site Configuration value for the question Will this instance be deployed behind a load balancer as part of a site configuration? and click Next.
    6. Enter a password for amldapuser under the Agent Information settings, confirm it and click Next.

      This password must be different from the one previously entered for amadmin.
    7. Ensure the Summary is correct and click Create Configuration.
    8. After the configuration is complete, click Proceed to Login.

  8. Login to the OpenSSO console as the default amadmin administrator using the corresponding password.

Deploying the Web Service Provider on Glassfish

  1. Download using the WSS Agent Download link on the OpenSSO Download page.
  2. Make a directory named wss_bits and unzip the contents of the into it.
  3. Deploy a web service provider (WSP) into the wsp Glassfish domain.

    Use the StockService sample included with the provider download. Information on deploying the Stock Service can be found in the README located in the samples/glassfish directory of the exploded
  4. Stop the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin stop-domain wsp
  5. Change to the GLASSFISH_INSTALL_DIR/domains/wsp/config/ directory and make the following modifications to the domain.xml file.

    1. Add the following code fragment under the <message-security-config auth-layer="HttpServlet"> tag.

      NOTE : Create the <message-security-config auth-layer="HttpServlet"> tag if it is not already present.

      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMHttpAuthModule"
      provider-id="FAMHttpProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMHttpAuthModule"
      provider-id="FAMAuthHttpProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsc"/>
    2. Add the following code fragments under the <message-security-config auth-layer="SOAP"> tag.

      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-SAML-HolderOfKey" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="SAML-HolderOfKey"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-SAML-SenderVouches" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="SAML-SenderVouches"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-X509Token" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="X509Token"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertySAMLToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertySAMLToken"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMClientAuthModule"
      provider-id="FAMClientProvider" provider-type="client">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsc"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-UserNameToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="UserNameToken"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-UserNameToken-Plain" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="UserNameToken-Plain"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertyX509Token" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertyX509Token"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-LibertyBearerToken" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="LibertyBearerToken"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="wsp"/>
      <provider-config class-name="com.sun.identity.wssagents.glassfish.FAMServerAuthModule"
      provider-id="FAMServerProvider-Anonymous" provider-type="server">
      <request-policy auth-source="content"/>
      <response-policy auth-source="content"/>
      <property name="providername" value="Anonymous"/>
    3. Start the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

      ./asadmin start-domain wsp

  6. Log in to the Glassfish console as administrator.

Configuring the WSP to Use the Security Token Service

These configurations are done using the Glassfish console and on the machine to which the StockService WSP has been deployed.
  1. From the navigation bar on the left of the Glassfish console, click Configuration > Security > Message Security > SOAP.
  2. Click on the Message Security tab under SOAP.
  3. From the drop down menu, select the providers previously added, FAMServerProvider and FAMClientProvider, as the Default Provider and Default Client Provider, respectively.
  4. Copy /openssowssproviders/resources/ to the GLASSFISH_INSTALL_DIR/domains/wsp/config directory and update the copied properties file to reflect your environment.

    Refer to
  5. OPTIONAL: Create a GLASSFISH_INSTALL_DIR/addons/accessmanager directory if not already present.
  6. Copy all the JAR files from the /wss_bits/openssowssproviders/lib directory to the GLASSFISH_INSTALL_DIR/addons/accessmanager directory.
  7. Put GLASSFISH_INSTALL_DIR/addons/accessmanager/openssowssproviders.jar and GLASSFISH_INSTALL_DIR/domains/wsp/config in the classpath of the machine on which the WSP is deployed.
  8. To change the logging level, from the navigation bar on the left of the Glassfish console, click Application Server.
  9. Click the Logging tab on the right of the console.
  10. Click the Log Levels tab.
  11. Select FINEST from the drop down list next to Security.
  12. Click Save.
  13. Copy /wss_bits/openssowssproviders/resources/wsit-client.xml and /wss_bits/openssowssproviders/resources/famsts-client.wsdl to GLASSFISH_INSTALL_DIR/domains/wsp/config.
  14. Update GLASSFISH_INSTALL_DIR/domains/wsp/config/famsts-client.wsdl to reflect the actual path to the keystore.jks file.

    Trade out @KEYSTORE_LOCATION@ with the actual value.
  15. Restart the wsp domain using the asadmin command line tool located in /GLASSFISH_INSTALL_DIR/bin.

    ./asadmin stop-domain wsp
    ./asadmin start-domain wsp

Configuring the Web Service Client (WSC) and the WSP to Use the Security Token Service

These configurations are done using the OpenSSO console.

  1. Log in to the OpenSSO console as the administrator and click through the Configuration > Agents > Web Service Client tabs.
  2. Under Agent, click wsc.
  3. Under Security, select STSSecurity as the Security Mechanism.
  4. For STS Configuration, select SecurityTokenService from the drop down.
  5. Under Signing and Encryption, check the Is Request Signed and Is Response Signature Verified options.
  6. Select the following under Key Store:

    Public Key Alias of Web Service Provider - test
    Private Key Alias - test
    Key Store Usage - Default
  7. Enter the end point of the web service.

    For example,
  8. Click OK.
  9. Back on the home page of the OpenSSO console, click through Configuration > Agents > Web Service Provider.
  10. This time, under Agent, click wsp.
  11. Under Security, select Anonymous, SAML2-HolderOfKey, SAML2-SenderVouches, and UserName Token as the Security Mechanism.
  12. For STS Configuration, select SecurityTokenService from the drop down.
  13. Under Signing and Encryption, check the Is Response Signed and Is Request Signature Verified options.
  14. Select the following under Key Store:

    Public Key Alias of Web Service Provider - test
    Private Key Alias - test
    Key Store Usage - choose Default and uncheck the box next to the Preserve Security Headers in the Message option.
  15. Click OK.

Configuring the WSC to Use the Security Token Service

Use the StandAloneStockClient sample included with the provider download. Information on deploying this sample can be found in the README located in the samples/glassfish directory of the exploded

  1. Put the following JAR files in the classpath of the machine on which the WSC is deployed.

    • appserv-rt.jar
    • j2ee.jar
    • javaee.jar
    • webservices-rt.jar
    • webservices-tools.jar
    • openssoclientsdk.jar
  2. Copy /openssowssproviders/resources/ to the GLASSFISH_INSTALL_DIR/domains/wsp/config directory and update the copied properties file to reflect your environment.

    Refer to Ensure the values for the following properties are correct.

    • com.sun.identity.saml.xmlsig.keystore
    • com.sun.identity.saml.xmlsig.storepass
    • com.sun.identity.saml.xmlsig.keypass
    • com.sun.identity.saml.xmlsig.certalias
    • com.sun.identity.classloader.client.jarsPath
  3. Put the directories containing the following files in the classpath.

    • wsit-client.xml
    • famsts-client.wsdl
  4. wsit-client.xml and famsts-client.wsdl are in the /osso_bits/openssowssproviders/resources/ directory.

  5. Update GLASSFISH_INSTALL_DIR/domains/wsp/config/famsts-client.wsdl to reflect the actual path to the keystore.jks file.

    Trade out @KEYSTORE_LOCATION@ with the actual value.

Now all communications between the configured WSP and WSC will be secured by the WSS provider and the Security Token Service. And speaking of tokens, how about The Lion Sleeps Tonight as performed by The Tokens, Pat (the hippo), and Stanley (the dog).

Friday Mar 28, 2008

When Peace Guides the

You might find it interesting to check out the beta site Sun employees create planets (feed aggregators based on keywords, features, or other criteria) and their created collection of links can be viewed by clicking the planet name. There is a planet specifically for OpenSSO but you might find other planets that might be useful also.

At this time, non-Sun employees can not create planets but, if you have an idea for one that might be beneficial, let me know and I can create it.

In honor of the aligning, here's the 5th Dimension singing their huuuuggggeee hit Aquarius/Let the Sunshine In (The Flesh Failures). These two songs are NOT a medley in the Broadway musical Hair for which they were both written - separately. The aggregation was most likely a genius idea from the head of producer Bones Howe.

Thursday Mar 27, 2008

A Primer on OpenSSO, Policy Agents and Pan's People

Here's a link to an excellent tutorial on getting started with OpenSSO and policy agents.

And now that you're finished, you just might want to loosen up so here is a clip of Pan's People, a group of females who would dance to a song on the BBC-TV music chart show Top of the Pops when the artist wasn't available to sing it live (or Memorex). (Think the Solid Gold dancers for those in the States.) This clip is the troupe dancing to Creedence Clearwater Revival's Green River.

And, of course, there's the even funnier take-off by French and Saunders' Pan's Indeedy People moving to Yellow River - with a long yellow cloth to boot.

Yellow River? Don't take me there.

Friday Mar 21, 2008

Configuring DSEE as a User Data Store is Easy

There are two ways to configure Sun Java System Directory Server Enterprise Edition (DSEE) as the user data store for OpenSSO.

  1. By configuring DSEE as a user data store during deployment.
  2. By preparing the DSEE manually.

The first option is easy-breezy. When you first launch OpenSSO, the configurator is displayed. By checking the Load UM Schema option and pointing to the instance of DSEE, that instance will be configured as the user data store.

The second option is a little less breezy. Follow this procedure to configure DSEE manually.

  1. Load the user attribute schema and index files into DSEE using ldapmodify.

    For example:

    ldapmodify -h host -p port -D"cn=directory manager" -w passwd -c -f file-name

    TIP: If you run into a SASL BIND error, use the -x option with ldapmodify.

    The schema and index files\* are (and can be found in):

    • /path-to-context-root/fam/WEB-INF/template/sms/sunone_schema2.ldif
    • /path-to-context-root/fam/WEB-INF/template/sms/ds_remote_schema.ldif
    • /path-to-context-root/fam/WEB-INF/template/openfm/fam_sds_schema.ldif (also in /fam/ldif/ and /opensso)
    • /path-to-context-root/fam/WEB-INF/template/openfm/fam_sds_index.ldif (also in /fam/ldif/)
    • /path-to-context-root/fam/WEB-INF/template/sms/index.ldif
    • /path-to-context-root/fam/WEB-INF/template/sms/plugin.ldif

    path-to-context-root is specific to the web container on which OpenSSO is deployed.

    \*NOTE: The schema files are platform and root suffix neutral; you can retrieve these files from any instance of OpenSSO and load them to any other instance. The index files, on the other hand, are not neutral. index.ldif and fam_sds_index.ldif contain the back-end database name of the instance to which they were originally deployed. For example, if originally deployed in a system with a dc=red,dc=sun1,dc=com root suffix, an index entry might look like:

    dn: cn=nsroledn,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=memberof,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=iplanet-am-static-group-dn,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=iplanet-am-modifiable-by,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=sunxmlkeyvalue,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=o,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=ou,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=sunPreferredDomain,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=associatedDomain,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config
    dn: cn=sunOrganizationAlias,cn=index,cn=red,cn=ldbm database,cn=plugins,cn=config

    Thus, in order to use these index files on a system with the root suffix of dc=sun2,dc=com, replace all occurrences of red in the files with sun2 before loading.

  2. Prepare the DIT for the default Data Store configuration by creating the base container entries.

    1. Copy the following text into a file named /tmp/new/ldapentries.
      dn: ou=people,dc=sun,dc=com
      objectClass: top
      objectClass: organizationalUnit
      dn: ou=groups,dc=sun,dc=com
      objectClass: top
      objectClass: organizationalUnit

      NOTE: Be sure to replace dc=sun,dc=com with your root suffix.
    2. Run the following command:

      ldapmodify -h host -p port -D"cn=directory manager" -w passwd -c -a -f /tmp/new/ldapentries
Now you can login to OpenSSO and create a data store with the FAM schema using DSEE. The bind DN is cn=dsameuser,ou=dsame users,ROOT_SUFFIX.

Now to remind you just how easy that was - here's the Barenaked Ladies with Easy.

Monday Mar 17, 2008

Telecommunication with an SSL Data Store

This blog entry is two years old. You can do this with the OpenSSO configurator now when you deploy the WAR.

I found this procedure internally and I thought it might help some externally. The engineer was configuring OpenSSO to communicate with an SSL data store.

  1. Set up your data store with SSL enabled.
  2. Import a root certificate for your data store to the web container using the following command:

    JAVA_HOME/bin/keytool -import -keystore keystore_file_name -keyalg RSA -trustcacerts -alias alias_name -storepass changeit -file certificate_file_name

    • For Sun Application Server 9.1, keystore_file_name in the default domain1 is /opt/SUNWappserver/domains/domain1/config/cacerts.jks
    • For Sun Web Server 7.0U1, keystore_file_name is /usr/jdk/entsys-j2se/jre/lib/security/cacerts
  3. Restart the web container.
  4. Deploy opensso.war.
    When running the WAR configurator, you can't point to the SSL port so you must point to the non-SSL port.
  5. Log into the administration console as the administrator; by default amadmin.
  6. Create a new data store configuration or edit the existing one.
    Click the Data Stores tab for the appropriate realm under the Access Control tab. Be sure to enable the following two attributes:
    • LDAP Server must have the host name and SSL port of the SSL data store.
    • LDAP SSL must be checked.
  7. Create a new User that points to the SSL port of the data store.
    Click the Directory Configuration tab after choosing the appropriate Server under the Sites and Servers tab, located under the Configuration tab. Select New... under User and configure the user so that it points to the SSL port.
  8. Delete the default non-SSL user and save.
And now OpenSSO is configured to communicate with a secure directory. In celebration here's another type of communication: Telecommunication, live by A Flock of Seagulls.

Friday Mar 14, 2008

Brand New

Buried deep in an entry I wrote a few days ago on setting up a SAMLv2 IDP proxy was some exciting (well - to me anyway) news concerning keystores: a keystore is now created during deployment of the opensso.war. Previously, we had product documentation and FAQ to explain how to create a keystore using keytool. Now, this default keystore (and it's included key entry) can be used for customer demos after configuring the OpenSSO WAR. The keystore contains one key entry represented by the alias test. The keystore file password is secret as is the password used to protect the entry. This keystore alias is used by the Security Token Service to sign the generated security tokens. (Now you can see why you should use this alias only for customer demos.)

So, in honor of our new keystore, here's vintage Melanie singing her song, Brand New Key.




« July 2016