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.

Monday May 12, 2008

Spinning for Swag at JavaOne

The content of conferences like CommunityOne and JavaOne is all well and good. The technical sessions are informative and meeting new people is fun but, getting to the heart of the matter, it's the swag that lasts longest. When it comes to free stuff, we're all Paris Hilton. If I can take home more than a handful of good t-shirts my wardrobe is set for the year. And I'll always play with the (SWAG ALERT) slinky that now sits on my desk.

Although Moscone Center was the place in San Francisco last week for the kick-off of JavaOne, you also had the opportunity to attend virtually (Second Life) and via webcasts. CommunityOne (with attendees numbering 50% more than last year) started the week with a full-day of free technical sessions pertaining to open-source projects. (There was a soft opening, as it was referred to by the Moscone Center employees, on Sunday for start-ups.)

SWAG ALERT: OpenSolaris cloth bag with new logo!

First thing I noticed when I arrived for the CommunityOne General Session was the lack of food. Last year, a big breakfast buffet was generously laid out but not this year so I quickly grabbed a spinach/egg/feta burrito and found out a seat for the General Session. (Food is swag but maybe we should consider ourselves lucky that there was none.)

SPOTTED: Peter Fernandez calling out my cap.

Ian Murdock opened the CommunityOne General Session and then brought Jonathan Schwartz up for some remarks. The general theme of all these speeches (including the panel discussion) was the dichotomy between open and closed (monolithic, proprietary) software. Sun is fully committed to opening the source code for all its applications, thus allowing innovation everywhere rather than in one place. Sun software is becoming simple, small pieces loosely joined together to produce a whole that is greater than the sum of its parts.

SWAG ALERT: CommunityOne water bottle (stacked at a water fountain)

A shout out to Stormy Peters for mentioning the need to document code and lamenting that there were not enough technical writers in the world.

SWAG ALERT: Netbeans cloth bag and cap

The big software of the day (besides OpenSolaris) was Netbeans which had different sessions all day. I attended the first to find out what was new with the product.

SWAG ALERT: GOOD CommunityOne t-shirt

SPOTTED: Paul Davies, Emily Xu, Shih-Yun Huang, Robertis Tongbram, and the real-life Ken Harper chatting during the lunch break.

Other CommunityOne sessions I attended were An Introduction to Web 2.0, Examining a Sample Application Built in Three Ways (very enlightening), Liberating Web Services, and Open Sourcing Music. Finally, our very own SuperPat Patterson moderated the OpenSSO Workshop with Daniel Raskin and Nick Wooler.

SWAG ALERT: GOOD Glassfish t-shirt

On Tuesday, JavaOne began with it's General Session (which included an appearance by Neil Young).

Following this I was through learning and ready to work the Spinning Duke game. All attendees can spin the wheel and win an appropriate prize, depending on the level at which the wheel stopped. The top-level prize was a JavaOne backpack from last year's conference.

SWAG ALERT: JavaOne backpack from last year's conference - legitimately won via a spin of the wheel

At one point, a gent walked up to me to ask about the backpack. "Is that the backpack from the 2006 JavaOne Conference?"

"Actually, I believe it is from last year's conference." I answered.

"Hmmm. I don't think so. Let me check." Out came his iPhone and the gent started scrolling.

"Tell me you have a picture of every JavaOne backpack on your iPhone?" I asked.

"Kind of geeky." he stated sheepishly.

He showed me the screen of his iPhone and I said, "Considering you have a picture of the backpack with a Post-It attached that reads 06?, I will take your word that it is from two years ago."

"Actually, I did that last night from memory so you could be right."

"Last night?"

"Yea. I felt the need to organize my swag."

SPOTTED: Shripad Pakti and Diann Olden checking out the Pavilion

People and their swag. I couldn't even keep count of how many spinners asked me for an extra commuter mug or a second dangling sea anemone because they have two kids who will fight over it. (Believe me, no child was hurt over a dangling sea anemone.)

SWAG ALERT: GOOD Google t-shirt

SPOTTED: JohnD, John Spencer, and Scott Carver checking out the Pavilion on Sun employee night.

SWAG ALERT: Ericsson yo-yo with enough string for a three foot tall person

By the time my two days of spinning and swagging were finished I was ready for a long weekend. While walking to Muni, I ignored a man playing a long, brass instrument for change in the subway underpass. It sounded like a clarinet but was NOT a clarinet and he was playing badly. Or maybe I had just given too much already.

OK, I'll give one more thing: a look at Dame Shirley Bassey hitting the notes in her version of Spinning Wheel.

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.

Wednesday Mar 12, 2008

Developers Call to Federation/Web Services/SAML Arms

This is a link to a PDF of the Federation, SAMLv2, and Web Services chapters of the FAM8 Developers Guide. This is a skeleton of what is going in the book. Let me know if you see something (or know of something) that I missed.

And here's another type of arms that belongs to someone with whom Elvis Presley wants to lie.

Loving Arms has been covered by many artists since it's original recording in the 60s. My favorite versions are Elvis's, the Dixie Chicks, and Ms. Millie Jackson. What's yours?

Tuesday Mar 11, 2008

Setting Up a SAMLv2 IDP Proxy and Pulling Shapes

A SAMLv2 Identity Proxy acts as both an identity provider and a service provider. If an identity provider receives a request for authentication it cannot directly authenticate, it may issue its own authentication request to a second identity provider that can authenticate the principal. The identity provider that received the original authentication request is the identity provider proxy. The response from the second identity provider can be used to authenticate the principal and the identity provider proxy can issue an assertion of its own in response to the original authentication request.

Here is the procedure for setting up a SAMLv2 Identity Provider Proxy using OpenSSO.

  1. Install and deploy OpenSSO on three separate machines - preferably in different domains.
    Make sure each machine has a different cookie name when deployed.
  2. Create your own keystore using keytool.
    You can also use the keystore.jks file created during deployment of OpenSSO. It is located in /opensso/opensso directory and contains a private key named test and an associated public certificate. The keystore password and key password for the entry are secret. For information on creating your own keystore, see the keystore FAQ.
  3. Encrypt the keystore password for each host machine.
    The following procedure should be done on each host machine.

    1. Access encode.jsp by typing the following URL in a web browser.
    2. Type your password in the Password to Encode field and click encode.
    3. Copy the resulting string into the keystore.jks, .keypass and .storepass files on the appropriate machine.
      These files should be in the /opensso/opensso/ directory.
  4. Type http://host:domain/opensso/famadm.jsp?cmd=create-metadata-template in a browser and use the famadm web interface to generate the service provider metadata.
    Use the following values:
    • entityid = YOUR_SP_HOST_URL
    • Enable : metadata, extended
    • serviceprovider : /sp
    • spscertalias : test
    • specertalias : test

    NOTE: It is recommended that you separate the standard and extended metadata into separate files.
  5. Type http://host:domain/opensso/famadm.jsp?cmd=create-metadata-template in a browser and use the famadm web interface to generate the identity provider metadata.
    Use the following values:
    • entityid = YOUR_IDP_HOST_URL
    • Enable : metadata, extended
    • serviceprovider : /idp
    • idpscertalias : test
    • idpecertalias : test

    NOTE: It is recommended that you separate the standard and extended metadata into separate files.
  6. Type http://host:domain/opensso/famadm.jsp?cmd=create-metadata-template in a browser and use the famadm web interface to generate the identity provider proxy metadata.
    Use the following values:
    • entityid = YOUR_PROXY_HOST_URL
    • Enable : metadata, extended
    • serviceprovider : /proxysp
    • identityprovider : /proxyidp
    • spscertalias : test
    • specertalias : test
    • idpscertalias : test
    • idpecertalias : test

    NOTE: It is recommended that you separate the standard and extended metadata into separate files.
  7. Type http://host:domain/opensso/famadm.jsp?cmd=create-circle-of-trust in a browser and use the famadm web interface to create circle of trust.
    Do this on each host machine, naming the circles as follows:
    • On the service provider host machine: spcot
    • On the identity provider host machine: idpcot
    • On the identity provider proxy host machine: proxycot
  8. Copy the appropriate standard and extended metadata onto each host machine.
  9. Type http://host:domain/opensso/famadm.jsp?cmd=import-entity in a browser and use the famadm web interface to import the metadata and create the entity.
    You will need to specify the name of the circle of trust into which you are importing the metadata.
  10. Using the same URL as in the previous step, do the following:

    1. Import the service provider metadata to the Identity Provider Proxy
    2. Import the identity provider metadata to the Identity Provider Proxy
    3. Import the service provider portion of the identity provider proxy metadata to the identity provider
    4. Import the identity provider portion of the identity provider proxy metadata to the service provider

    NOTE: When loading the metadata to the identity provider proxy be sure the host=0 - signifying the remote host.
  11. On the service provider machine, login to the console and click the Federation tab.
    You should see SP and Proxy.
  12. Click on the service provider host, followed by the service provider tab and enable:

    1. Authentication Requests Signed:
    2. Assertions Signed:
    3. Artifact Response:
    4. Logout Request:
    5. Logout Response :
    6. Manage Name ID Request :
    7. Manage Name ID Response:
    8. Enable : IDPProxy
Now you can perform the SAMLv2 test cases for single sign-on and logout through a proxy - or take another kind of test. This video from The Pipettes is for a song called Pull Shapes. Questions follow.

  1. What is pull shapes?
    Anyone who has spent time in the UK might know this one.
  2. What film does this video ape?
    Anyone who relishes trash films (the good kind) might know this one.

Thursday Mar 06, 2008

The One-Level Wildcard for Policy Logic

UPDATE-3/21/08: The one-level wildcard is currently only available to the J2EE agents - not the web agents.

After putting together the couplet entries on policy logic in OpenSSO and wildcard matches in policy agents, I received an email from Bhavna, one of Sun's Federated Access Manager engineering gurus, who wrote - and I cut and paste:

good addition. You might want to add some information on one level wild card too which, by default, is "-\*-"
unfortunately we don't have much documentation on it.

NOTE: I'm thankful for that last sentence myself.

Well here is the scoop that turns our couplet into a triplet. The one-level wildcard was introduced in Sun Java System Access Manager 7.1. The wildcard itself is -\*- and it matches only the level for which it stands without crossing delimiter boundaries. A policy can include the one-level wildcard in resource names to allow and deny access. For example, if you allow access to\*-/d in a policy definition then access to will be allowed but access to will be denied. -\*- would match any character but only at the defined level.

And, in honor of all the gurus at Sun, here's a music clip from a very funny and sweet movie called The Guru. It's American-financed but filmed in the Bollywood-style. (Any suggestions on some Bollywood movies I should see would be appreciated.) The song is called Chori Chori which from my perusal on the internet means "secretly".

Once you've met The Guru, love will never sound the same.

Tuesday Mar 04, 2008

Wildcard Matches in Policy Agents

A comment was left in yesterday's entry on policy logic concerning the lack of consistency in how the different policy agents treat the wildcard. Now I am not an agent expert but I did manage to gather some information for Mr. Robinson that, I hope, helps to shed some light on how the wildcard is used by agents.

The Policy Service in OpenSSO supports policy definitions using an asterisk (\*) as the wildcard. Only \* is supported as a wildcard and it can not be escaped as in \\\*.

A \* :

  • matches zero or more occurrences of any character.
  • spans across multiple levels in a URL.

The following matching rules assume (rightfully so) the wildcard character is \* and the delimiter character is /.

  1. \* matches zero or more characters, including /, in the resource name.
  2. \* matches one or more characters, including /, if the \* appears at the end of the resource name and it is immediately preceded by a /. For example, abc/\* doesn't match abc.
  3. Multiple consecutive / characters don't match with a single /. For example, abc/\*/xyz doesn't match abc/xyz.
  4. For purposes of comparison, trailing / characters will not be considered as part of the resource name. For example, abc/ or abc// will be treated the same as abc.

Here are some examples:

Pattern Matches Doesn't Match\*\*.html\*/abc\*/def

And while we're on the subject of wild things, think of X, the seminal punk band of all time. The song in this video isn't one they wrote (for that you'd have to check out Johnny Hit and Run Paulene, Nausea or Los Angeles) but it does segue nicely. Here's X covering The Trogg's (not Tone-Loc's) Wild Thing. And that's Chuck Berry on stage at the video's end - a wild thing in his own right.

UPDATE: For more information on policy logic and wildcards see the following entries:

Policy Logic in OpenSSO

Here's some information that, thanks to a comment from a member of the OpenSSO community, I found missing from our doc set. We wrote a great deal about policy but not a heck of a lot about policy logic.

NOTE: If you'd like an overview of policy and authorization take a look at the Authorization and Policy Service chapter in the Sun Java System Access Manager 7.1 Technical overview or the OpenSSO Policy Service Architecture document. I'll wait.

Done? OK. Now that you know everything there is to know about policy, here is the last piece. All of the following should be satisfied for a policy to be applicable to a request.

  1. The Resource Name defined in a policy's Rules should match that of the protected, requested resource. The match can be an exact literal match or one due to the presence of wild cards. Currently, policy agents only support http:// and https:// URLs as a Resource Name; they do not support IP addresses in place of the host name. Wild cards are supported as a substitution for a protocol, a host name, a port number, or a resource - as in:

  2. The requesting user should satisfy at least one of the Subject(s) defined by the policy. For example, if the Subject type is defined as Access Manager Identity Subject, the requesting user should be a member of the role selected in the policy.
  3. At least one Condition in EACH selected Condition Type defined in a policy should be satisfied by the requesting user, resource and/or environment parameters. For example, if the policy is defined with two Time conditions and two IP Address/DNS Name conditions, the request should satisfy at least one Time condition and at least one IP Address/DNS Name condition.

And sometimes policies collide; when this happens, the following rules take effect:
  1. When multiple policies are applicable to a particular resource, the order in which the policies are evaluated is not deterministic.
  2. If a policy decision for a requested action is boolean, a value of false overrides one of true. For example, when deciding authorization for a web URL, deny overrides allow.
  3. If a policy decision for a requested action is boolean and the request is determined to be false based on policies evaluated thus far, no further policies will be evaluated for the requested action. This behavior can be changed by toggling the Continue Evaluation On Deny Decision attribute in the Policy Configuration Service.

So, in conclusion, sometimes musical styles collide also. When this happens there are no rules. You might get Sammy Davis, Jr. (smokin' a ciggy butt) and Cass Elliot singing their Las Vegas-style version of the Peter, Paul and Mary classic, I Dig Rock and Roll Music.

Or you get Mary dancing like she's in a mosh pit to an acoustic version of the same song.

UPDATE: For more information on policy logic and wildcards see the following entries:

Wednesday Feb 27, 2008

Are you going to JavaOne? CommunityOne?

I'll be there.

For the uninitiated, JavaOne is an annual four day conference, held in San Francisco and dedicated to all things Java. Aside from the Pavilion (which takes up both sides of the famed Moscone Center) in which exhibitors and sponsors promote their wares, JavaOne 2008 also has technical sessions, birds-of-a-feather discussions (read small, informal groups talking about a specific topic), panels, and hands-on labs. The 2008 conference runs from May 6-9, 2008; registration links, the session schedule and a lot more information can be found on the JavaOne 2008 home page.

This year, JavaOne has also scheduled the 2nd CommunityOne conference for members of the open source community. This free day presents sessions on everything you might need to know to get started creating and deploying the next generation infrastructure using open source projects. CommunityOne is the day before JavaOne on May 5, 2008. CommunityOne is FREE and open to anyone who registers.

The third piece of the JavaOne pie is Java University. This one day program of training courses is also held (unfortunately) on May 5, 2008 so you must pick and choose between Java University events and CommunityOne events. Check out my JavaOne blog entry from 2007. (You might also be interested in how I got there.)

Finally, in honor of the return of JavaOne to the City by the Bay, here's a clip of Jeanette MacDonald singing the ultimate San Francisco song called, concisely, San Francisco. Sorry, San Francisco (Be Sure To Wear Some Flowers in Your Hair) and I Left My Heart in San Francisco but it is.

Unfortunately this clip is colorized but, in looking for the original black and white footage, I found the earthquake sequence (in black and white) from the same movie, San Francisco. They don't make 'em like this anymore and I should know - I just saw 300.

OK, so now I feel terribly guilty about dissing San Francisco (Be Sure To Wear Some Flowers in Your Hair) and I Left My Heart in San Francisco so here are links to those performances by Scott McKenzie and Tony Bennett, respectively. But after watching these you better get back to work.

Friday Feb 22, 2008

OpenSSO Build 2 is Gone Daddy Gone

OK, you can still get Build 2 but why would you if OpenSSO Build 3 is now available for download. New features in Build 3 include:
  • JBOSS support
  • Geronimo support
  • OpenDS replication
  • Upgrade / Co-existence
  • Timed task changes in session and LDAP
  • New SAMLv2 profiles (AuthnQuery & Naming ID Mapping)
  • Legacy DIT support from AM 7.x DIT
  • Assorted issue fixes
Check out the README for supported web containers and workarounds. Instructions for deploying Build 2 on Glassfish can be found in this blog entry. Still worked for Build 3.

And since we're discussing two builds of the same thing, check out Gone Daddy Gone. First the incredible Build 1 by the Violent Femmes:

And now the mundane Build 2 by Gnarls Barkley (which offers no new features):

In the case of Gone Daddy Gone, I'm sticking with the original build.



« July 2016