Friday May 15, 2009

The OpenSSO Docs Wiki Heats Up

If you haven't visited the OpenSSO Resource Center lately, go have a look. My colleagues on the docs team have been doing a fantastic job of posting high quality information there. The site gets richer and richer every day.

Today, the site hit the mother lode when Gina from the OpenSSO writers team exposed a wealth of troubleshooting tips and FAQs based on support cases on the Community Contributions page of the Resource Center. Together with the How To's and White Papers already present on the page, this makes for extremely interesting reading.

I gotta say, I love working on a technology that has this quality and quantity of informaton available out in the open.

Monday Dec 22, 2008

Changing Default GlassFish v3 Prelude Port Numbers 4848, 8080, and 8181

When you create courses, you sometimes do crazy things like installing multiple GlassFish domain administration servers (DAS) in a single host.

When you install GlassFish, it gives you default port numbers of of 4848 (for administration), 8080 (for the HTTP listener), and 8181 (for the HTTPS listener). But what do you do if you want to change them?

I got a few ideas googling "asadmin port number" and the like but couldn't really find a good example. So, I figured out how you do it and thought I would post an example in case anyone finds themselves in the same predicament as I did today.

Here are some examples that work in GlassFish v3 Prelude:

  1. To change the HTTP port to 10080:

    asadmin set server.http-service.http-listener.http-listener-1.port=10080

  2. To change the HTTPS port to 10443:

    asadmin set server.http-service.http-listener.http-listener-2.port=10443

  3. To change the administration server port to 14848:

    asadmin set server.http-service.http-listener.admin-listener.port=14848

It's handy to know you can grep for server properties in GlassFish v3 Prelude as follows:

asadmin get server | grep listener

shows all the properties with the text "listener" in them.

In GlassFish v3 Prelude, you can set port numbers for administration and the HTTP listener in the installer - but not for the HTTPS listener. You might find yourself needing to explicitly specify the administration port in your asadmin command. For example:

asadmin set --port 14848 server.http-service.http-listener.http-listener-2.port=10443

For GlassFish v2, use the asadmin get command as described here.

Hope this is helpful to someone.

Wednesday Dec 10, 2008

Installing OpenSSO Enterprise 8.0 on GlassFish v3 Prelude Release

I've been building some training for OpenSSO Enterprise 8.0, and I want to use GlassFish v3 Prelude Release as my OpenSSO web container for this training.

So I pulled down the GlassFish release, installed it, deployed OpenSSO, started up the OpenSSO console, and logged in. But instead of seeing the console main page, the login page appeared a second time, with the user name and password fields blanked out.

The issue has to do with cookie handling. Dennis noted it in his blog entry here.

Well, it turns out getting OpenSSO Enterprise 8.0 to run on this release of GlassFish is a snap - if you know the workaround. Here are the steps for Solaris OS:
  1. Obtain the GlassFish v3 Prelude Release from

  2. Run the command (which is what you obtained when you downloaded GlassFish). Specify installation options as needed. The rest of these instructions assume that you specified /opt/glassfish as your installation directory.

  3. Start the domain administration server: /opt/glassfish/bin/asadmin start-domain domain1

  4. Start a browser, then start the GlassFish administration console ( and log in to the console.

  5. Click Application Server (in the left window pane), then the JVM Settings tab, then the JVM Options tab.

  6. Click the Add JVM Option button. A new line opens up.

  7. Add the following option: (this is the workaround).

  8. Change the -client option to -server, and change the -Xmx512m option to at least -Xmx1024m (as documented in the OpenSSO Installation and Configuration Guide.

  9. Log out of the GlassFish admin console.

  10. Restart the GlassFish DAS:
      /opt/glassfish/bin/asadmin stop-domain domain1
      /opt/glassfish/bin/asadmin start-domain domain1

  11. Deploy the OpenSSO web application and configure it.

  12. Start the OpenSSO console and log in. This should take you to the console's main page.

Friday Sep 26, 2008

OpenSSO Deployment Screencasts Are on YouTube

I was cruising through YouTube and happened to come across these screencasts of the OpenSSO Deployment course, WSPL-AM-3508-D. Check them out!

Thanks to Waylon in New Zealand for putting these up. I'm looking forward to seeing more of them!

Lab 1, Exercise 1

Lab 1, Exercise 2

Lab 1, Exercise 3

Monday Aug 18, 2008

Three, Two, One ... Go!

I'm pleased to be able to let you know that training for the OpenSSO Early Access Release is now available at

The training comprises five self-paced, downloadable labs that take you through a complex OpenSSO deployment. You deploy two Apache Tomcat servers, SSL-enable them, install a software load balancer, install OpenSSO into the environment, and configure OpenSSO for session failover. Then you install an example web server and an example application server, and install Policy Agent software to see how OpenSSO protects web sites and J2EE applications.

Go to the OpenSSO site and click Training on the blue bar on the left. Follow the links that take you to the Sun Learning Services Online Lab Community.

From there, you will be able to get the labs, at no cost. The only thing you need before you can access the labs is a login ID at My Sun.

After following the setup instructions, you'll have:

  • A PDF-format workbook that contains the step-by-instructions for doing the labs

  • A Solaris 10, Update 5 virtual machine preconfigured with all the software you need to do five labs. This virtual machine has some interesting capabilities:

    • Four whole root zones, so scenarios requiring multiple hosts can be easily and quickly configured

    • All the zones are fully encapsulated in ZFS file systems. A script that exploits ZFS features lets students roll the virtual machine forward or backwards, to do any lab in the workbook. For example, if you are interested only in configuring session failover, you could roll the machine forward to Lab 3 (the session failover lab).

      If you then changed your mind and decided you wanted to do the lab in which you run the OpenSSO configurator, you could roll the machine back to the start of Lab 2. And, if you were then to decide you wanted to do the labs from scratch, you could roll the machine back to the starting point for Lab 1.

      Don't want to do the labs at all - just need to build OpenSSO demos? Roll the machine forward to the start point for Lab 6.
      The idea behind this type of learning is flexibility: "just in time, just enough, just for me."

Saturday Aug 09, 2008

And Now, The OpenSSO Early Access Release

An Early Access release of OpenSSO is now available in the form of OpenSSO Express Build 5.

Participate in this program and help Sun make the first commercial offering of OpenSSO as good as it gets.

If you're not familiar with OpenSSO, here are some selected quotes from Felix Gaehtgens' very nice review of OpenSSO for Kuppinger Cole:

  • The development of OpenSSO is lively, and the product has improved dramatically over the years.
  • The initial teething problems have long been overcome - specifically the limited amount of “committers” ... Nowadays, the OpenSSO project has around 60 committers, 10 of them being external, i.e. non Sun-employees. The community and Sun engineers now have a reputation for being quite responsive in helping community members while in development.
  • This new announcement (of the OpenSSO release model) is a very good step forward for Sun’s customers ... Customers have the best of both worlds – a very innovative product with a large and active engineering base, together with professional support.

Nice stuff. Nice product. Developed by the nicest engineering team I've had the privilege of working downstream from, and I've worked downstream from a lot of engineering teams over the years. And the most responsive - Felix sure got that one right.

Tuesday Feb 06, 2007

A Fun New Toy, Part 1

No, not the carbon fiber bike I've been lusting over. This time, my toy is a fun new site on the web.

SSOCircle is a site developed by Hu Liu, a consultant based in Steinbach, Germany. As it says on SSOCircle's home page, "SSOCircle is for those who want to federate their applications or just want to get some SSO experience. SSOCircle provides a ready to use Identity Provider."

My plate has been very full at work lately - I've been updating the Access Manager training course, AKA AM-3480 for Access Manager 7.1 among other things - but when I saw the February 2 entry on Pat's blog, I couldn't resist giving this thing a try.

Hu Liu has set up a SAML 2.0 identity provider based on the OpenSSO project. It should work with any SAML 2.0-compliant service provider (SP), and there's functionality at SSOCircle to add your own SP to the SSOCircle circle of trust (CoT). For demonstration purposes, I used the the sample service provider site that Pat mentions in his blog entry. This site has already been set up as an SP in the SSOCircle CoT. (Setting up an SP to go in the SSOCircle CoT is now on my "to do" list, and when I get around to doing it, I'll blog about it.) It took all of two minutes to set up my account at SSOCircle and federate with the sample SP site. Here are the steps I followed, if you want to try it out:

  1. From the SSOCircle home page, I click Login / Register and register as a new user.

  2. I wait for my registration confirmation e-mail to come back, and when it does, I follow the instructions in it to complete the account registration process.

  3. I go back to the SSOCircle home page and log in.

  4. I look at my cookies (because it is always a good idea to look to the cookie) and find a cookie named iPlanetDirectoryPro with a reference to an SSO token - a sure sign that OpenSSO is in the house.

  5. So at this stage, I'm authenticated with the identity provider, and have the SSO token reference to prove it. Now I go to the SP site. It is important to notice that the page heading reads "ZXID SP Federated SSO (user NOT logged in, no session)."

  6. I click Login to (SAML20: Artifact).

  7. A new screen comes up with the title, "ZXID SP Management (user logged in, session active)."

So, voila, I'm an authenticated user at the SP without having had to log in there. The SP delegated authentication to the IdP. I have an account at the IdP but not at the SP, but I am still able to use the SP's site. That's Internet SSO functionality - one of the basic features of federated identity.

Imagine if you are the administrator at the SP. Your company or organization has established a business relationship with the identity provider that says that you trust anyone who has authenticated to the IdP to let them use your web services. No provisioning, no account maintenance, and - we hope - a very quick ramp up time.

I'll check out the ramp up time - how long it takes me to set up an SP and enter the SSOCircle CoT - in a future entry.




« July 2016