Installing Directory Server on Solaris

As you all know, Directory Services are key to OpenSSO. We support many of them but, beside OpenDS which we use for our embedded configuration store, one of the best LDAP Directory server out there is Sun’s Directory Server Enterprise Edition (DSEE for short). In a typical deployment you will want to store user data on a separate Directory Service.

I always thought that, starting from a freshly installed Solaris 10 box, the deployment of DSEE is everything but smooth. This post lists the initial steps one has to take to perform such deployment and follow the DSEE Administration guide (your sole reference on the matter) . This was also strongly inspired by some excellent posts (listed at the end).

First a few assumptions:

• Our starting point is a machine that runs  Solaris 10. I used the latest release (Sept. ‘09) available here. All updates were applied after the installation.
• I’ll assume the installation is done as root. This might not be the optimal approach, security-wise, but I’m keeping it simple here.
• I’m installing DSEE via the JES 5 installer. JES (Java Enterprise System) is our main delivery system for lots of Sun’s software. The neat thing about JES is that it bundles applications together (e.g. Access Manager 7.1 and DSEE). In the present case I only installed DSEE and DSCC, the DS Control Center (a useful interface to administer DSEE deployments).

Now onto the steps:

1. The first step to be done is to configure DSCC by performing:
   <dsee install dir>/dscc6/bin/dsccsetup initialize
   Doing so results in an error from cacao: Cannot find property: [cacao embedded].
   The problem here is that JES reverted the version of cacao (Solaris’ Common Agent Container (more info here) to a previous one.
2. We need to reinstall cacao from the Solaris 10 CD. Look for the 2 following packages: SUNWcacaort, SUNWcacaodtrace To install them, change to the packages directory and enter:
   pkgadd -d . SUNWcacaort
   pkgadd -d . SUNWcacaodtrace
3. Start cacao: /usr/sbin/cacaoadm start
   You can verify it’s running fine with: cacaoadm status
4. You can now re-attempt to run the initialization (step 1). You should see a message saying that the DSCC Registry has been created successfully.
5. If you want to make sure cacao starts upon reboot, enter:
   /usr/sbin/cacaoadm enable
6. The the admin guide says to access DSCC through the Java Web Console in your browser. Well, we need to make sure it is running first:
   /usr/sbin/smcwebserver status
   Most likely it’s not…
7. Start the Java Web Server with:
   smcwebserver start
   Now you can access it with your browser and … Oops… it only listens on your localhost (127.0.0.1).
   To fix this, use svccfg:
   # /usr/sbin/svccfg
   # svc:> select system/webconsole
   # svc:/system/webconsole> setprop options/tcp_listen=true
   # svc:/system/webconsole>quit
   You’ll have to restart the Java Web Console at this point:
   /usr/sbin/smcwebserver restart
8. The Java Web Console is now accessible on the standard port 6789 (using https) and Voilà, the configuration of DSEE as specified in the Administration guide can now proceed unhindered.

Was this useful? Did you have a different DSEE install experience? If so, please let me know!

Some very useful links I used for this post:

1. http://oldmangriffous.blogspot.com/2008/10/centralised-authentication-on-solaris_26.html
2. http://www.tjhsst.edu/admin/livedoc/index.php/Sun_Java_System_Directory_Server

 

OAuth support: a summary of our work

A quick summary of the OAuth support we’ve recently added in a couple of key projects.

If you’re into RESTful web services and OAuth, we have implemented an extension to the Jersey project (the JAX-RS Reference Implementation). This extension allows for the signing and/or the verification of OAuth 1.0 based requests. It is based on a digital signature library accessed by server and client filters. Detailed information can be found here.

For people interested in a more integrated solution, we have also implemented a module for the open source project OpenSSO to supports OAuth as an authentication module. This module handles the Service Provider side, that is: token issuance, token & message verification as well as SSO session handling (to bridge with other protocols). This module is, for now, an extension to OpenSSO. In other words it is not yet part of the core OpenSSO and should be considered as more experimental. Beside the Java doc, a good source of information on this can be found in this article. There’s also Pat’s demo at Community One this year.

If you’re so inclined, give it a try – any feedback is more than welcome!

 

OAuth Security Issue

The more I think and read about the session fixation issue (see the official announcement here and additional info there) that has been discovered in OAuth, the more I’m convinced of the benefits Identity Federation brings to the table.

Think about it, the main issue (beside securing the callback URL which is reasonably easy to achieve) is the fact that the (service) Consumer and the Service Provider can’t currently be sure that the user that has initiated the OAuth flow (and thus has logged in at the Consumer site) is the same user that logs in the Service Provider during the authorization process. If something akin to SAML’s SSO model were in play (where identities of the principal at the consumer & SP site are federated in a privacy-preserving manner – meaning no correlation issue) then ensuring it is the same user would be a no brainer.

This also can be looked at from the token perspective and what information it conveys. Wouldn’t a SAML assertion be useful here?

Another interesting path would be to use something like Liberty’s Interaction Service to obtain confirmation from the user thus thwarting an attacker to obtain the access token in your name.

 

Winter’s arrived

The nice thing with living at the foot of the Alps and literally at the bottom of a hill is that you get to see lots of variations of the same place. The 2 photos below clearly illustrate that.

 

Hello world!

OK, not very original but I guess there must be one entry with this title…
For starters, let me say that this blog is basically the follow up of my previous blog that is still hosted here. Why moving to WordPress? No, no, I still work at SUN and although recent news have not been great, I’m fortunate to work on a pretty exciting project.
I did, however, want to try something else, change the tone and variety of my blog and since there’s so much time I can dedicate to writing blog entries I thought I’d try this (many thanks to Lauren for suggesting using WordPress and relentlessly encouraging me to blog again).