Wednesday Jun 04, 2008

Common Tasks and Common People

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

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

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

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

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

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

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

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

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

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

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

And here's the original from Pulp.

Wednesday May 21, 2008

You Gotta Get an Administrative User - and a Gimmick

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

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

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

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.

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.

Wednesday Feb 20, 2008

Removing and Redeploying OpenSSO

As a technical writer, I often have the need to remove a deployed instance of OpenSSO so I can redeploy and reconfigure the latest build and write some more interesting stuff about the latest features. It's very easy to do - just follow this procedure.

  1. From the Glassfish console, undeploy the WAR.
  2. From the command line, stop the Glassfish domain.
  3. From the command line, remove (recursively) the following directories:
    • opensso
    • AccessManager
  4. Remove the ZIP file you downloaded if you haven't already.
  5. Download the latest ZIP.
  6. Unzip the ZIP.
  7. Restart the Glassfish domain.
  8. Log in to the Glassfish console and redeploy the WAR.
    See this blog entry: OpenSSO Build 2 and Glassfish: Ready to Go for details.

Yes, folks, that's it. Files used to fly all over the place but now everything is organized for ease. And here's some ease to end the day with: the eas-y sound of the Seekers featuring the eas-y voice of Judith Dunham in a live rendition of their eas-y classic Georgy Girl. (Click the image to play.)

Monday Feb 18, 2008

King Leonidas Has Nothing On OpenSSO

According to SuperPat, OpenSSO has reached 600 members strong. That beats 300 hands down. Congratulations to all on this milestone!

Apologies to our distaff members for the song; you can look at the pictures though. There's even a full length version to enjoy.

The Weather Girls. Gotta love 'em.

Wednesday Feb 13, 2008

Configuring OpenSSO Without configurator.jsp

After OpenSSO WAR is deployed in the appropriate web container, the application is launched for the first time and you configure it using the configurator.jsp. If you don't want to use configurator.jsp you can do either of the following.
  1. Write a simple Java class that does an HTTP post to configurator.jsp.
  2. Use wget to do a post from the command line.
So last night I watched The Lair of The White Worm. The 1988 horror comedy wasn't so great (although I feel it might improve with age) but there was one party scene with a song about the D'Ampton worm which stopped my laundry folding. Here is the trailer for the movie with the D'Ampton worm song playing in the background.

If you liked the sound of this Pogues-esque folk song you can go directly to youtube to see the party scene in its entirety (with song lyrics in the description). Unfortunately for us, the user who uploaded the D'Ampton worm scene disabled embedding.

Tuesday Feb 12, 2008

Deploying OpenSSO on WebSphere 6.1 AIX

Thanks to Emily, developer extraordinaire, for the following procedure.

Following are the steps you need to run OpenSSO on WebSphere 6.1 AIX:
  1. After deploying the WAR and before running the configurator, modify the /export/IBM/WebSphere/AppServer/profiles/AppSrv01/properties/server.policy and /export/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/itsyNode01Cell/nodes/itsyNode01/servers/server1/server.xml files as follows.

    CAUTION: Backup both files before making any modifications.

    1. Add the following Java security permissions to server.policy:

      // ADDITIONS FOR Access Manager
      grant {
      permission "\*", "connect,accept,resolve";
      permission java.util.PropertyPermission "\*", "read, write";
      permission java.lang.RuntimePermission "modifyThreadGroup";
      permission java.lang.RuntimePermission "setFactory";
      permission java.lang.RuntimePermission "accessClassInPackage.\*";
      permission java.util.logging.LoggingPermission "control";
      permission java.lang.RuntimePermission "shutdownHooks";
      permission "getLoginConfiguration";
      permission "setLoginConfiguration";
      permission "modifyPrincipals";
      permission "createLoginContext.\*";
      permission "\*", "read,write,execute,delete";
      permission java.util.PropertyPermission "java.util.logging.config.class", "write";
      permission "removeProvider.SUN";
      permission "insertProvider.SUN";
      permission "doAs";
      permission java.util.PropertyPermission "", "write";
      permission java.util.PropertyPermission "", "write";
      permission java.util.PropertyPermission "", "write";
      permission java.util.PropertyPermission "user.language", "write";
      permission "\*", "accept";
      permission "setHostnameVerifier";
      permission "putProviderProperty.IAIK";
      permission "removeProvider.IAIK";
      permission "insertProvider.IAIK";
      // END OF ADDITIONS FOR Access Manager
    2. Modify server.xml as follows:

      1. Add the following JVM entries:

      2. If using SSL, add the following properties and JVM entries (in bold):

        </cacheGroups> </services>
        <properties xmi:id="Property_1120370477732" name="amCryptoDescriptor.provider" value="IBMJCE" required="false"/>
        <properties xmi:id="Property_1120370511939" name="amKeyGenDescriptor.provider" value="IBMJCE" required="false"/>
        -DamCryptoDescriptor.provider=IBMJCE -DamKeyGenDescriptor.provider=IBMJCE"/>
  2. After configuring OpenSSO but before running the SAMLv2 sample configurator, change the JSP compile version to 1.5 using the jdkSourceLevel parameter.

    WebSphere Application Server version 6.1 uses JDK 1.5. By default though, the SAMLv2 JSP's JDK source level uses JDK 1.3. As the SAMLv2 sample configurator uses the JDK 1.5 syntax, running it with the default source level will not work. You can add, change or delete any JSP engine configuration parameters (including the source level) with the WEB-INF/ibm-web-ext.xmi file. A sample of the WEB-INF/ibm-web-ext.xmi file is pasted below. The lines in bold text are JSP engine configuration parameters.

    <?xml version="1.0" encoding="UTF-8"?>
    <webappext:WebAppExtension xmi:version="2.0" xmlns:xmi=
    xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi" xmi:id="WebAppExtension_1" reloadInterval="9" reloadingEnabled="true" defaultErrorPage="error.jsp" additionalClassPath="" fileServingEnabled="true" directoryBrowsingEnabled="false" serveServletsByClassnameEnabled="true" autoRequestEncoding="true" autoResponseEncoding="false"
    <webApp href="WEB-INF/web.xml#WebApp_1"/>
    <jspAttributes xmi:id="JSPAttribute_1" name="useThreadTagPool" value="true"/>
    <jspAttributes xmi:id="JSPAttribute_2" name="verbose" value="false"/>
    <jspAttributes xmi:id="JSPAttribute_3" name="deprecation" value="false"/>
    <jspAttributes xmi:id="JSPAttribute_4" name="reloadEnabled" value="true"/>
    <jspAttributes xmi:id="JSPAttribute_5" name="reloadInterval" value="5"/>
    <jspAttributes xmi:id="JSPAttribute_6" name="keepgenerated" value="true"/>
    <!-- <jspAttributes xmi:id="JSPAttribute_7" name="trackDependencies" value="true"/> -->

    Note: The integer in the JSPAttribute_n ID must be unique within the file.

    The following procedure illustrates how to modify the WEB-INF/ibm-web-ext.xmi file parameters. An example where we have added the jdkSourceLevel parameter follows after. jdkSourceLevel is a new JSP engine parameter which was introduced in WebSphere Application Server version 6.1 to support JDK 5. (Here is a listing of JSP engine parameters.) jdkSourceLevel should be used instead of the compileWithAssert parameter, although compileWithAssert still works in version 6.1. jdkSourceLevel parameter values are:
    • 13 (default) - This value will disable all new language features of JDK 1.4 and JDK 5.0.
    • 14 - This value will enable the use of the assertion facility and will disable all new language features of JDK 5.0.
    • 15 - This value will enable the use of the assertion facility and all new language features of JDK 5.0.

    CAUTION: Backup WEB-INF/ibm-web-ext.xmi before making any modifications.

    1. Open WEB-INF/ibm-web-ext.xmi.
      WEB-INF/ibm-web-ext.xmi is located in either of the following directories.

      • The web module's configuration directory as in:

        WAS_ROOT/profiles//profilename//config/cells//cellname//applications//enterpriseappname// deployments//deployedname///webmodulename/
      • The web modules's binaries directory which is created if an application was deployed with the flag Use Binary Configuration set to true. In this case, the directory is:


    2. Edit WEB-INF/ibm-web-ext.xmi as follows.

      • To add configuration parameters, use the format:

        xmi:id="JSPAttribute_6" name="parametername" value="parametervalue"/>
      • To remove configuration parameters, either delete the line from the file, or enclose the statement with brackets and dashes as in:

        <!-- --> tags.
    3. For example, you can change /WEB-INF/ibm-web-ext.xmi to:

      <?xml version="1.0" encoding="UTF-8"?> < xmi:version="2.0" xmlns:xmi="""webappext.xmi" xmi:id="WebAppExtension_1185836603523"> <webApp href="WEB-INF/web.xml#WebApp_1185836603521"/> <jspAttributes xmi:id="JSPAttribute_1185836603523" name="reloadEnabled" value="true"/> <jspAttributes xmi:id="JSPAttribute_1185836603524" name="reloadInterval" value="10"/> <jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/> </>

    4. Save the file.
    5. Restart the application.

      It is not necessary to restart WebSphere for parameter changes to take effect. However, some JSP engine configuration parameters affect the Java source code that is generated for a JSP. If such a parameter is changed, you must retranslate the JSP files in the web module to regenerate Java source. You can use the batch compiler to retranslate all the JSP files in a web module which uses the JSP engine configuration parameters set in the ibm-web-ext.xmi unless specifically overriden. JSP engine configuration parameters identifies the parameters that affect the generated Java source.
  3. Before running setup -p configuration path, modify the setup script by inserting

    -D"amCryptoDescriptor.provider=IBMJCE" -D"amKeyGenDescriptor.provider=IBMJCE"

    before -cp on the last line and save the file.
  4. Before running famadm do the following:

    • Add the :${TOOLS_HOME}/lib/xalan.jar to the classpath after openfedlib.jar.
    • Add the line

      -D"amKeyGenDescriptor.provider=IBMJCE" -D"amCryptoDescriptor.provider=IBMJCE"

      before com.sun.identity.cli.CommandManager AND before in the famadm file and save it.
  5. Before running ampassword add

    -D"amCryptoDescriptor.provider=IBMJCE" -D"amKeyGenDescriptor.provider=IBMJCE"

    before AND before in the ampassword file and save it.
  6. And in honor of our developer extraordinaire, here is Adam Green with his song and video entitled, what else, Emily.

Monday Feb 11, 2008

Federated Access Manager TOI, Session 3

Friday, February 8 was the third and final session of the Federated Access Manager TOI. Following are links to the first two session entries, the topics covered in this third session, and my notes.


FAM8 supports upgrade from:
  • JES AM versions of 6.3/7.0/7.1 (6.2 TBD)
  • AM 7.1 War based installations
  • FM 7.0 to FAM 8.0

  • Supports backwards compatibility of all existing features (with exceptions eg. IDFF)
  • AM 7.0/7.1 Client SDK and Full AM SDK versions compatible with FAM 8.0.
  • Modes
    • Legacy to Legacy or Realm
    • Realm to Realm
Must upgrade all AM server instances and all AM SDK instances


NOTE: Use the same URI from your previous install (use amserver rather than fam) or you will have to change URI in many places not accessed by upgrade scripts.

  • Upgrade instances of directory servers and web containers
  • Upgrade the FAM8 bits with UI customizations and regenerate WAR
  • Deploy FAM8 WAR and configure

FAM8 supports co-existance with:
  • AM 7.0 ,AM 7.1 with FAM 8.0 (Realm/Legacy)
  • FM 7.0 with FAM 8.0 (Legacy)(TBD)

Security Token Service

Security Token Service (STS) is a web service that provides the issuance and management of security tokens. It is built as a part of the OpenSSO WAR and deployed as a web service end point (servlet).
  • Speaks WS-Trust protocol
  • Allows plugins for different token implementations
  • Allows plugins for different token validations
  • Provides WS-Trust protocol-based client APIs for clients and applications to access STS
  • Provides WS-I BSP based security tokens such as UserName,X509,SAML,etc.

Sequence Flow:

Configured under the Agent tab (profiles) in GUI

Uses WS-Metadata Exchange protocol (MEX)

Web Services Security

Information on docs.sun

Samples to be included:

The client could be
  • End user identity
  • Web services client application identity
Embedded Config Store: OpenDS

Embed open source OpenDS in FAM 8 - not productized Sun DS

2 modes: single server or mutiple instances

Info in blog entries:

3rd Party Access Manager Product Integration

  • Simple SSO integration between FAM and SiteMinder and Oracle Access Manager in same internet domain
  • Enable legacy OAM and SM deployments for Federation protocols
My notes that you, the reader, would not understand:
third party AM in IDP Environment slide
5 and 6 as they are are optional steps
5 should be 4
6 should be 5
4 should be 6

Session Failover

Using Oracle Berkeley DB Java Edition
  • 100% pure Java for platform independence
  • Optimized for Java applications that require high throughput and concurrency
  • Direct Persistence Layer (DPL) API for EJB-style POJO persitence, as well as a Java Collections API
  • Single JAR file for easy integration
Nothing to document as this is all transparent to user

Berkeley DB is nothing but a bunch of API (?)

Security (JCE/JSS)

Support JCE and JSS
  • Encryption Class
  • Secure Random Class
  • SSL Socket Factory
    • netscape.ldap.factory.JSSESocketFactory
Federal Information Processing Standards (FIPS)

FIPS currently supported on Sun WS, and Sun APP Server EE (not glassfish)

FAM/IDM Integration
Rahul Gopal

Main components involved
  • SunAccessManagerRealmResourceAdapter - an IDM resource adapter used to plug-in backend systems
  • AM Policy Agent to protect IDM resources

So, after three days of meetings and note taking, let's relax now with some music and comedy from Alison Moyet and Dawn French. Here's the video for Whsipering Your Name.

Wednesday Feb 06, 2008

Federated Access Manager TOI, Session 2

This morning was the second session for the Federated Access Manager TOI. Following are the topics covered (with notes).

Session 1

Secure Attribute Exchange
SAMLv2 profiles
  • Assertion Query/Request Profile
    • Query existing SAML2 assertions based on specific criteria (authentication context, assertion identifier, etc.)
    • Query initiator is the SAML Requester
      Initiates the profile by sending a query message to SAML authority
    • Responder is the SAML Authority
      Validates and processes the query to issue a response
    • Supports:
      • Attribute Query (request attributes from a specific identity - successful response is assertion containing requested attributes) Basic Attribute and X509 Subject Attribute Queries
      • Authentication Query (request assertion for a principal based on the authentication context - successful response is assertion(s) containing the authentication statements available to the principal)
        Supports SOAP only
      • Assertion Query (request existing assertion(s) using assertion(s) identifier - assertion must be cached)
      • Authorization Decision Query (asks if a certain resource is accessible to a particular principal - made to authorization authority/policy engine)
        XACML authzn decision is an extension of this

  • Enhanced Client or Proxy (ECP)
    • Specifies interactions between enhanced clients or proxies (eg. HTTP proxy) and SPs and IDPs
    • ECP acts as a SOAP intermediary between the SP and IDP
    • SSO Profile with PAOS Binding
    • FAM 8.0 SAMLv2 IDP and SP are able to process request received from ECP
    • Arrow of step 6 should be going the other way and some type of authentication is required between 5 and 6
    • FAM 8.0 SAMLv2 IDP and SP can process request received from ECP
    • ECP Client included as part of Opensso Extensions not FAM - can be used for testing
      • Proxy Version (HTTP)
      • Java Based Version (HTTPs)
  • Name Identifier Management
    Allows the change of principal's name identifier (shared between IDP and SP) after federation (possibly for security purposes or maybe IDP has a timing rule)
    • IDP can issue a ManageNameIDRequest to the SP to change the name identifier shared between them from a previous SSO
    • SP can issue a ManageNameIDRequest to attach an alias to its Principal
    • ManageNameIDResponse is returned after processing the request
    • Subsequent communication between SP & IDP will use the new name identifier
  • Name Identifier Mapping
  • POST Binding
    Added support for POST binding for a number of profiles
    • Web SSO Profile
    • Single Logout Profile
    • Name Identifier Management
    • Name Identifier Termination
  • Affiliations is a feature not a profile - will be implemented with SAML2 but will be very close to what we already have for IDFF
  • Represents access control policies, requests and response to get polices and authzn decisions
  • XACMLv2.0 current standard
  • Support SAML2 profile of XACML
    • XACMLAuthzDecisionQuery
    • XACMLAuthzDecisionStatement
  • Aravindan says should be doc'ed under Policy
  • Sample in path-to-context-root/fam/samples/sdk directory
  • XACML Design Doc
IDP Proxy
  • IDP proxy is one entity that acts as both IDP and SP
  • In wei -> ping -> jamie example, ping is IDP proxy
  • Supports:
    • SSO
    • SSO with IDP disco service
    • SLO
  • IDP proxy supports chaining
  • useIntroductionforIDPproxy attribute is to turn on Disco Service
  • #1 use case in slides is the default
Multi Protocol Support

Support for IDFF, SAML2, WS-Fed in one circle of trust
  • Enables a circle-of-trust to contain entities supporting different kind of federation protocols
  • Enables SSO and SLO to work across heterogeneous protocols within the same circle-of-trust - mainly to enable SSO and SLO for the same session shared among different ID-FF/SAML2/WS-Federation IDPs hosted on the same FAM instance
  • Sample included in which user will create a circle of trust containing one multi-federation protocol Identity Provider instance and three Service Provider instances speaking ID-FF, SAMLv2 and WS-Federation protocol

Identity Services
  • Allow developers to invoke FAM without knowledge of product
  • Developer uses php et al and may not need our client API
  • Use IDE to implement in your application
  • WSDL URL used in IDE
  • REST URL used with scripting languages
  • Change name of feature

Monday Feb 04, 2008

Federated Access Manager TOI, Session 1

There is a point in the timeline of a software release where engineers deliver what those in the 'biz' call a TOI or transfer of information. Engineers put together slide decks and spend a few hours telling anyone who will listen what to expect from the upcoming release. Each presentation ends with a question and answer session from the interested parties (documentation writers, QA engineers, training, development engineers, etc.). Today we had the first session for the Federated Access Manager 8.0 TOI and here are my notes.

Supported Software
  • Operating Systems
    • Solaris
    • Linux
    • Windows
    • AIX for WebSphere only
  • Containers:
    • Sun WS
    • Sun AS
    • WebLogic
    • WebSphere
    • Oracle AS
    • JBoss
    • Tomcat
    • Geronimo for Solaris only (Geronimo can install Jetty AS and Tomcat AS; FAM supports only TomCat)
  • Directory servers as user stores
    • Sun DS
    • AD
    • IBM Tivoli DS
Installation and Configuration
Ping, Jon
  • FAM server bits require JDK 1.5 or higher
  • Client of FAM requires JDK 1.4 or higher
  • Single WAR deployment
  • Configuration Wizard guides the users through a seven (or so) screen installation process; it replaces the one page configurator.jsp

Centralized Server Configuration Data
  • An embedded directory server offers centralized server configuration data management
    Previously each configured instance of the product had it's own server configuration data stored local to the server product in and serverconfig.xml. Now each FAM instance has its own branch in an instance of an embedded data store offering ease in managing multiple instances of FAM. Embedded data store can be Sun Directory Server or open source OpenDS. The latter is installed with FAM8.
  • A FAM instance's service configuration data properties used to be stored in and serverconfig.xml. They are now stored in the centralized data store under a sub-configuration of the Platform Service branch.
  • Modify centralized server configuration data using
    1. FAM console: under Configuration -> Sites & Servers click on the appropriate name/hyperlink from the list of servers displayed to view and edit the centralized server configuration data.
    2. famadm CLI using subcommands such as:
      1. list-server-cfg is to list the configuration of an server instance
      2. remove-server-cfg is to remove a configuration’s property values
      3. update-server-cfg is to set configuration’s property values
Bootstrapping FAM

WAR points to bootstrap file which points to centralized server configuration data store which holds bootstrapping data that is retrieved for bootstrapping process

famadm CLI
  • amadmin CLI will ship for two more releases only; over this time will be deprecated and replaced by famadm CLI
  • famadm CLI supports all commands of amadmin
  • famadm still works with In the absence of code>, famadm retrieves server configuration from the centralized depository.
  • Installation
    1. Unzip in temporary directory on server where FAM is hosted and type setup with a value for the installation directory of FAM server
    2. Must be setup for each instance of FAM - no global properties (although, in general, all global properties are reproduced in the instance service configuration data)
  • amAdmin password must always be in a separate file and pointed to during CLI input
  • Legacy DITs can use famadm CLI
  • If you don't specify -protocol option - defaults to SAMLv2
  • DON'T DOCUMENT: there is also a web-based CLI purely for internal usage that will not be supported for release (ie:
    I don't believe the fact that I am mentioning this web-based CLI here is documenting. If it is, I'm sure I'll hear about it.
  • New subcommands
    1. backup and restore server configuration data by exporting from DS to file or importing file to DS; SMS info that is exported here is global to FAM
      encryptsecret option, used for purposes of export and import, takes any string and is stored only in the head of the person who entered it - NOT part of service configuration data
    2. create and update datastores (also can be done from console)
    3. export-server and import-server options: exports only properties that had been stored in the late and lamented and serverconfig.xml; server config data that is exported here is per FAM instance
  • famadm is used for agent config

  • Secure Attribute Exchange
  • New SAML2 profiles (ECP, AttributeQuery, AuthnQuery, X509 Profile, IDP Proxy, ...) all should be supported by the time of release
  • WS-Federation
  • SSO/SLO across multiple protocols
  • Bulk Federation preassigns a name identifier for a list of users at both ends of federation transaction
    Only for IDFF or SAML2
    AM71 is PERL-based; FAM 8 is Java-based
Centralized Agent Management and Agent 3.0
  • Agent install/uninstall via agentadmin CLI packaged with agent ZIP/WAR and installed on agent server
  • Centralized agent management - agent config data is now in service config store not IDRepo store (Data Stores) which was under realm tab - now under Configuration tab
  • still exists but has fewer properties - only local bootstrap data
    Additional info will be stored locally in (local configuration data) while embedded server configuration data store will hold centralized configuration data
  • Support local config for backward compatibility and centralized config
    Benefit of choosing local config - 2.2 agent customers deploy FAM8; agents are sometimes controlled by org's partners and thus they can have local control over centralized org control
    1. Agent starts up and reads local bootstrap properties and gets Naming URL and makes call to Auth Service (agent needs to authenticate to server first)
    2. Auth calls IdRepo which calls SMS which checks username and PW in Centralized Agent Config data (under FAM config data root)
    3. Gets SSOToken then returns to agent config data to get agent's config data location (local or central depending on config of agent)
    NOTE: Find out about Attribute service on Wednesday (REST)
  • agent config hot swapping - if property is hot swappable and I change the value of it during runtime the value changes on the fly
  • can enable notification and polling
  • agent grouping - share common config properties among multiple agent instances (ease of mngt feature)
  • no admin specific to agents (like policy and amadmin)
  • agent upgrade - new feature that automates the upgrade process

Web Services Security

  • Security Token Service
  • Web Services Security (API, Framework, Plug-ins) securing client web services, add plug-in without config(?)

Common Tasks
  • New tab in console to access feature setup wizards (aka workflows) for easy customer configuration
  • Initial tasks are federation-based (supports SAML2 currently; will support IDFF by release)
    • Simplified IDP/SP setup (minimal customer input, can take input from URL or file)
    • COT setup
    Wizrds also offer SSO verification between IDP and SP


  • 6.3 console is no longer available for legacy mode install; only Directory Management tab will show up for legacy support (Jon)
  • Identity Services - ???
  • 3rd Party Integration
    • FAM + CA's SiteMinder (SSO, Federation)
    • FAM + Oracle's Access Manager

Thursday Jan 24, 2008

Host Machine and Domain Name Changes: Access Manager 7.1

UPDATE: The completed document has been published to here. The link to the review copy below has been disabled.

I've just put together a technical note on what to do if the host machine or domain name changes for an instance of Access Manager 7.1 (WAR deployment only). It contains procedures for modifying properties and/or files in both a regular environment and in a federation environment. Here is a PDF version I sent out for engineering review. A complete HTML version should be posted to the Access Manager 7.1 documentation set on next week after I receive any comments.

There are other things you can do when a host name changes. For example, here is what was done when the host name changed on The Match Game. It's a long clip but you get to see the late Brett Sommers, the late Charles Nelson Reilly, the late Gene Rayburn, and the late Eva Gabor! Or is it Jolie? Or is it Zsa Zsa? Wait...Zsa Zsa is not late.

Tuesday Jan 15, 2008

OpenSSO & OpenDS Sitting in a Tree, K-I-S-S...

In case you hadn't noticed, OpenSSO build 2 (the soon-to-be christened Federated Access Manager) now stores its configuration data in a data store rather than a flat file. OpenDS is the new embedded configuration store, replacing the previous flat file implementation where configuration files were over the place (okay, there was sms). Now, OpenDS is installed with OpenSSO and the configuration data is stored.

The installed version of OpenDS is not complete (for example, the bin scripts have been removed to make the opensso.war as small as possible). But you can always download, explode it and point the script parameters to the configuration directory (config_dir_specified_in_configurator/opends). This will most probably change as the OpenDS builds stabilize.

Some things based on this move have already changed. For example, famadm is a utility that lets you manage your OpenSSO installation from the command line. When famadm was developed you needed to point to during setup. But from OpenSSO build 2, is now stored in an instance of OpenDS. So during setup you need to point famadm to a bootstrap file named, appropriately enough, bootstrap. bootstrap is located under the directory defined during configuration as the Configuration Directory.

The concept is that the CLI will read the bootstrap file, contact OpenDS, fetch the appropriate properties, and bootstrap itself.

So to bring it full-circle, and to tout what I will be doing on my long holiday weekend (which starts as soon as I publish this entry), here's KISS.

Friday Jan 04, 2008

Changing the Cookie Name in OpenSSO

I found this information in a comment so I figured I'd write it to an entry - in case anyway needs to change the cookie name in OpenSSO which, by default, is not editable.

  1. Login in to the console and click Configuration.
  2. Click Sites and Servers.
  3. Click the server name in the "Servers" table.
  4. On the Edit server name page, click the Security tab and then Inheritance Settings.
  5. Search for "Cookie Name" in the table and uncheck the box
  6. Save the page and click the Back to Server profile button.

You will now see the Cookie Name field is editable and you can change it.

And since we're talking cookies - it must be Cookie Time! So here's a clip of Troop Beverly Hills singing Cookie Time in one of my favorite 80s movie. And for those in the know Jenny Lewis of Rilo Kiley plays Shelly Long's daughter. Can you pick her out?

That's her at about 53 seconds. You can also spot Rosario from Will and Grace (Shelley Morrison) playing the maracas. And since I got you interested here's Jenny with Rilo Kiley singing Silver Lining.

Sunday Dec 09, 2007

Federated Access Manager 8.0 Roadmap and Features

I have been asked one particular question many times over the last few months and have been fudging my answer because way back when I wrote an entry that attempted to answer this question I was chastised by some muckety-mucks. On Friday, I was searching for some information and, lo and behold, found that Daniel Raskin, our relatively new marketing guru, had written a blog regarding the answer to the very same question I have been hesitating to answer: can you give me some information regarding FAM 8.0 roadmap and features? So, here are links to the blog entries that answer that question. Way to go, Daniel!

Federated Access Manager 8.0 -- The Overview (Part I)

Federated Access Manager 8.0 -- The Features (Part II)

On Saturday, I was searching for something fun to watch and found this clip of one of the all-time great comics, Totie Fields. Way to go, Totie!

Tuesday Dec 04, 2007

Updated OpenSSO FAQ

I took a moment last week to update the OpenSSO FAQ Center. The only question I have now is...

Friday Nov 30, 2007

OpenSSO Build 2 and Glassfish: Ready to Go

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.
  1. Using a browser, download glassfish-installer-v2-b58g.jar from
  2. 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.
  3. Change into the glassfish directory.
  4. Run the following commands:

    chmod -R +x lib/ant/bin

    lib/ant/bin/ant -f setup.xml
  5. After a successful build, change to the root directory and start the default domain:

    glassfish/bin/asadmin start-domain domain1
  6. Using a browser, verify the server is running by accessing http://machine.domain:8080.

    You should get a Server Running page.
  7. Login to Glassfish as admin (PW: adminadmin) by accessing the console at https://machine.domain:4848.
  8. Back on the command line, make an opensso directory and change into it.
  9. Using a browser, download Build 2. (This latest stable build will be at this location next week.)
  10. Back on the command line, unzip the zip.
  11. In the Glassfish console, click Web Applications on the left side.
  12. On the right side, click Deploy..., browse for opensso.war, and click OK.

    The WAR will be deployed.
  13. When finished, click Launch.

    The following screen is displayed.

  14. I chose Simple which, in turn, displayed this screen:

  15. Enter the default amAdmin password: admin123 and press Configure.

    The configuration screen is displayed. I clicked View Process Log and watched:

  16. 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 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.

Monday Nov 26, 2007

OpenSSO Download Page Changes

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:
  • Formally named, 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; for instance, and 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; Build 2 will be available soon. The 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.
  • contains third party libraries needed to build the OpenSSO source code. See the Build Instructions for information on how to use this.
  • 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

\*\*David Bowie

Wednesday Nov 14, 2007

The OpenSSO WAR Name Game

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!!

Sunday Nov 11, 2007

The NEW Federated Access Manager 8.0 Developer's Guide

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 happy happy as...oh! A dog and his ball.

Max and his tennis ball, that is.



« June 2016