Today I installed Glassfish, Sun's open source application server, and OpenSSO Build 2, Sun's open source access manager server. I used a machine running Solaris 10. Glassfish uses either JDK 1.5 or 1.6 so I added /usr/jdk/instances/jdk1.5.0/bin to the path property in my .profile file. Additionally, I set my JAVA_HOME to /usr/jdk/instances/jdk1.5.0. Seven months back, I installed Glassfish and it was pretty easy although there were some caveats. Today, there were no caveats. Deploying the OpenSSO WAR, as has been the case, was a cool drink of water.
Using the command line, extract the file using:
java -Xmx256m -jar glassfish-installer-v2-b58g.jar
This created a glassfish directory with everything inside. I liked this. So many times I have extracted a JAR to find files flying all over the place.
Change into the glassfish directory.
Run the following commands:
chmod -R +x lib/ant/binlib/ant/bin/ant -f setup.xml
After a successful build, change to the root directory and start the default domain:
glassfish/bin/asadmin start-domain domain1
Using a browser, verify the server is running by accessing http://machine.domain:8080.
You should get a Server Running page.
Login to Glassfish as admin (PW: adminadmin) by accessing the console at https://machine.domain:4848.
Back on the command line, make an opensso directory and change into it.
Using a browser, download Build 2. (This latest stable build will be at this location next week.)
Back on the command line, unzip the zip.
In the Glassfish console, click Web Applications on the left side.
On the right side, click Deploy..., browse for opensso.war, and click OK.
The WAR will be deployed.
When finished, click Launch.The following screen is displayed.
I chose Simple which, in turn, displayed this screen:
Enter the default amAdmin password: admin123 and press Configure.
The configuration screen is displayed. I clicked View Process Log and watched:
I was too excited to wait five seconds so I clicked to get the login page at http://machine.domain:8080, typed in my credentials and was ready to go...as Republica was, back in the day.
This is the overseas version, not the US remix with ridiculous overdubbed guitars that sounds like Paris Hilton's wonky left eye looks.
Last week I attempted to explain the myriad downloads available on opensso. This week we modified the OpenSSO download page so it is more concise and understandable. This page will hopefully be used as is for eons to come.
With the new version you can download:
opensso.zip Formally named fam.zip, this file includes the deployable opensso.war web archive, relevant Sun libraries, administration tools, samples, and the client SDK. It contains code culled from the amserver and federation directories.
NOTE: Some of these items are themselves compressed files within the compressed opensso.zip; for instance, fam-client.zip and openssosamples.zip.
opensso.zip is the most complete download available. I say most complete because it does not contain a few of the authentication modules based on third-party code. Build 1 is the most recent stable version of opensso.zip; Build 2 will be available soon. The opensso.zip download under the Periodic Builds table is pushed twice a week. Within the ZIP, you can use opensso.war to create specialized WARs to deploy, for example, the console or Distributed Authentication only. Instructions are included in the deployable-war directory. These WARs were previously available as separate downloads.
famclientsdk.jar contains the complete client SDK including the federation library code which can be used to build a remote federation-based service provider.
NOTE: The one change I'd like to see is opensso reflected in the name of this JAR. Although "A foolish consistency is the hobgoblin of little minds"\*, this consistency is not foolish.
opensso-sun-extlib.zip contains third party libraries needed to build the OpenSSO source code. See the Build Instructions for information on how to use this.
openssosrc.zip contains the OpenSSO source code.
Older versions of OpenSSO and stable and nightly versions of the web and J2EE agents can also be downloaded from this page.
\*Ralph Waldo Emerson
This information refers to the older OpenSSO downloads.
There are so many different web archive (WAR), Java archive (JAR), ZIP (ZIP) files and directories that you can browse and download from opensso that I have decided to put down in bits my take on them - what they are and why they differ. (I am not writing about the lesser-known files and directories - only the full product downloads that people, understandably, get confused about. Most of the other archive files are fully explained at the pages I linked to above.)
Of all the directories that you can browse,
amserver contains the access control & management related source code we are developing for Federated Access Manager 8.0. This includes, but is not limited to, authentication, policy, session, and auditing code. It was derived from the non-federation related features developed for Access Manager. This directory becomes part of the fam.war (now opensso.war).
federation contains all federation related source code. This code is derived from features developed for Federation Manager and the SAMLv2 plugin. The federation directory contains these subdirectories:
library can be downloaded as openfedclientsdk.jar. This can be used in a client application to communicate with an instance of OpenSSO. (I haven't been able to figure out if this directory is part of fam.war. Comment if you know.)
openfm contains the federation code we are developing for the 2008 release of Federated Access Manager 8.0. It can be downloaded as part of fam.war. Unlike the amserver directory, I don't believe openfm can be downloaded as a separate WAR. (Back in the day, fam.war was called openfm.war; it no longer is.)
Again, fam.war is comprised of code and files from both the amserver (opensso.war) and federation directories. It is the open source version of what one day will be branded by Sun Microsystems as Federated Access Manager. Download, install, and watch the developing ball bounce.
Now let's end with a tip o' the hat to the originator of The Name Game. Here she is...the rockin' Shirley Ellis. Everyone do The Pony!!
I am the writer assigned to the Sun Java System Federated Access Manager 8.0 Developer's Guide. This tome will be released with the product in 2008. I predict a multitude of changes between the Access Manager 7.1 Developer's Guide and this new Developer's Guide. I have sent out a link to this blog entry because I'd like to solicit feedback from customers and the field as I am ramping up my documentation plan. I already have some of my own ideas but this is the perfect time to have your voice heard.
If you have any ideas on how I can improve the Developer's Guide, please comment me. I appreciate any input.
When you see the new Developer's Guide in 2008, you'll be as happy as...um...as happy as...hmmm...as happy as...oh! A dog and his ball.
Max and his tennis ball, that is.
There is a difference in how Access Manager is configured after deployment using the new WAR-based distribution as compared to the JES package-based installation (performed by the JES Installer) previously used. When Access Manager is installed using JES, by default, it is configured for LDAP authentication and has all its data defined in an LDAP directory. The LDAP tree contains thousands of records including configuration data (which includes administrator users and agent profiles) and sample user entry trees. When Access Manager is installed using the WAR file, by default, it is configured to use Data Store authentication. Additionally,the sample user data is stored in a flat file and, unless otherwise specified on the configurator page, Access Manager configuration data is also stored in the flat file. You can reconfigure an Access Manager realm to retrieve data from an LDAPv3-compliant directory after the fact but be sure to load the Access Manager schema during WAR configuration.