The following tasks are described in this blog entry:

• How to install Tomcat 6.x as the Application Server
• How to Install OpenSSO (instead of Federated Access Manager 8.0) on Tomcat 6.x.

NOTE TO READER: If you see anything that isn't clear or is outright incorrect, don't hesitate to leave a comment. I'll try to straighten it out.

I installed these two software pieces on a Solaris 10 SPARC machine. It doesn't matter much what operating system you install on as long as the system has a relatively new JDK version installed. I had JDK 1.5.

The thing to keep in mind about the instructions that follow is that the examples include UNIX commands only, since I installed on Solaris. The machine I was using was set to the bourne "sh" shell by default. I didn't mess with that. What do I know from shells? Many times, I'd try various UNIX commands until one worked. When I show the wording "For example", that means that that's  what worked for me.

The commands are just examples since operating systems vary. Even when one uses Solaris, as I did, the shell varies or some other aspect of the environment. So, the bottom line is that things will vary.
-------------------------------------------------------------

To Install Tomcat 6.x

PRE-INSTALL INFO:

The OpenSSO Release Notes page for OpenSSO build 4 are available at the following link:

http://download.java.net/general/opensso/stable/openssov1-build4/B4-ReleaseNotes.html

The Instructions in this blog entry are for a nightly build between build 4 and 5 and the Release Notes apply, but you don't really need to go out to that page since I've pasted the relevant Release Note info for Tomcat 6.x in the box that follows:

Tomcat 6.x 1. Do NOT use Tomcat 6.0.16 as it does not work with OpenSSO Build 4 2. Increase JVM option -Xmx to 1024M

Okay, so the instructions follow next for installing Tomcat 6.x. I adhered to the guidelines in the box above.

INSTALL STEPS:

1. Set the JAVA_HOME variable to an appropriate version of JDK
   For example:
   # JAVA_HOME="/usr/jdk/jdk1.5.0_12"
   # export JAVA_HOME
   # env
   There must be a thousand ways to do this depending upon one's environment. The commands above worked for me. The env command lists all the environment variables, so you can check to make sure JAVA_HOME is set properly.
   
   
2. Create a directory for the Tomcat 6 container.
   For example:
   # mkdir Tomcat-base
   
   
3. Change directories into the newly created directory.
   For example:
   # cd Tomcat-base
   
   
4. Download a Tomcat 6.x version supported by OpenSSO:
   I downloaded the following version:
   http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.14/bin/apache-tomcat-6.0.14.tar.gz
   Here's the link to the page where this file is available:
   http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.14/bin/
   From that page, depending upon how your browser is set up to handle downloads, you might want to right click the option apache-tomcat-6.0.14.tar.gz and select "Copy Link Location." That way you can control the exact location to which the download goes.
   
   
5. Uncompress the file.
   For example:
   # gunzip -c apache-tomcat-6.0.14.tar.gz | tar xvf -
   
   The above command is suggested by Pat Patterson. I added it to this entry after reading his comment (see his blog comment at the bottom of this entry).
   The below commands worked for me, but his command is clearly the way to go.
   # gunzip apache-tomcat-6.0.14.tar.gz
   # tar xvf apache-tomcat-6.0.14.tar
   I don't know much about such things. But I looked at the following
   page (There are many ways to uncompress a .tar.gz file. It took me a couple of attempts until I stumbled on those two commands above):
   http://www.gzip.org/
   
   
6. Edit the following Tomcat file as shown in the substeps that follow:
   /Tomcat-base/apache-tomcat-6.0.14/bin/catalina.sh
   
   
1. Open the catalina.sh file using your editor of choice.
   
   
2. Add the following string  including the quotation marks to the line shown in the examples in this substep:
   "-Xmx1G"
   Before Editing:
   JAVA_OPTS="$JAVA_OPTS "-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
   After Editing:
   JAVA_OPTS="$JAVA_OPTS "-Xmx1G" "-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
   
   
3. Save and close the file.
   
   
7. Start Tomcat as described in the substeps that follow.
   This is just to check that everything is working as expected.
   
   
1. Change directories to the location of the Tomcat startup script.
   For Example:
   # cd /Tomcat-base/apache-tomcat-6.0.14/bin
   
   
2. Issue the start up command.
   For example:
   # ./startup.sh
   
   
8. Use a browser to check that Tomcat has started:
   For example, in a browser window, go to the following location:
   http://TomcatHost.example.com:8080/
   
   Where TomcatHost is a place holder that you must replace with the name of the host machine to which you just installed Tomcat 6.0.14.
   
   If everything went properly, you will see the Apache Tomcat page.
   
   
9. Shutdown Tomcat.
   For example:
   # ./shutdown.sh
   

-------------------------------------------------------------

To Install OpenSSO (Jun 29, 2008 Build) on Tomcat 6.x

PRE-INSTALL INFO:

The OpenSSO downloads are available from this web page:
https://opensso.dev.java.net/public/use/index.html

On the above listed web page, the periodic builds are listed in the section labeled as such:
"Periodic OpenSSO and Client SDK Builds"

I downloaded the OpenSSO Zip, which at that time had the following timestamp: Sun Jun 29 09:00:05 PDT 2008. I didn't create a directory for the installation. I just used the root "/" directory to download the opensso.zip file and unzipped it right there (I'll probably download and unzip files in a more organized fashion in the future).

INSTALL STEPS:

1. Download the newest available OpenSSO build.
   I downloaded the following version:
   http://download.java.net/general/opensso/nightly/latest/opensso/opensso.zip
   Here's the link to the page where this file is available:
   http://download.java.net/general/opensso/nightly/latest/opensso/
   
   From there, you can right click the opensso.zip file and select "Copy Link Location" to control where you download the file. That page gives you the latest builds of OpenSSO available. Since I installed on June 29, 2008, I got the June 29 build, which is a periodic build between builds 4 and 5.
   
   
2. Unzip the opensso.zip file.
   For example:
   # unzip opensso.zip
   Since I unzipped the file in the root directory, this created the opensso directory at the following location: /opensso
   
   
3. Copy the opensso.war file from the distributed opensso files to the Tomcat webapps directory.
   For example:
   cp /opensso/deployable-war/opensso.war /Tomcat-base/apache-tomcat-6.0.14/webapps
   
   
4. Start Tomcat as described in the substeps that follow.
   Because the opensso.war file is in the Tomcat webapps directory, starting Tomcat deploys OpenSSO.
   
   
1. Change directories to the location of the Tomcat startup script.
   For Example:
   # cd /Tomcat-base/apache-tomcat-6.0.14/bin
   
   
2. Issue the start up command.
   For example:
   # ./startup.sh
   
   
5. Confirm that TomCat has started and OpenSSO has deployed as described in the substeps that follow:
   
   
1. Use a browser to check that Tomcat has started:
   For example, in a browser window, go to the following location:
   http://TomcatHost.example.com:8080/
   
   If everything went properly, you will see the Apache Tomcat page.
   
   
2. Add the string opensso to the URL in the browser window.
   For example:
   http://TomcatHost.example.com:8080/opensso
   
   If everything went properly, you will see the Sun Federated Access Manager page labeled Configuration Options.
   
   
6. Proceed with the configuration as described in the substeps that follow:
   You don't need to go with the default configuration, but that's what I did.
   
   
1. Click the link for Default Configuration.
   
   
2. Enter the same password for both of the Default User Fields: Password and Confirm.
   By the way, the password you enter here is used by you and other administrators to log into OpenSSO. At that Login page (which comes up when you visit http://TomcatHost.example.com:8080/opensso), the value to enter for the User Name field is amAdmin while the password is the one you are creating in this substep.
   
   
3. Enter the same password for both of the Default Agent Fields: Password and Confirm.
   Ensure that this password is different from the one you just created above.
   You might not ever need this password again. One situation you would need it is if you install Policy Agent 2.2 with this OpenSSO deployment. In that situation, this password would be needed. In that case, it is used in conjunction with the user name "UrlAccessAgent."
   
   
4. Click OK.
   
   The configuration process continues for a couple of minutes and then shows a configuration complete message.
   
   
7. Visit http://TomcatHost.example.com:8080/opensso again to confirm that you get the Sun Federated Access Manager login page.
   
   
8. Log in using the proper credentials.
   User Name is amAdmin and Password is the password you chose to go with amAdmin.
   

Ta da! That's it. You're in.

You can find links for Access Manager Policy Agent 2.2 for for Apache Tomcat 6.0, both the download and the document, on my Policy Agent 2.2 Documentation and Downloads page.

This agent was developed through the OpenSSO project.

You can find links for Access Manager Policy Agent 2.2 for SAP Enterprise Portal 7.0 and Web
Application Server 7.0, both the download and the document, on my Policy Agent 2.2 Documentation and Downloads page.

This agent was developed through the OpenSSO project.

Still 2.2 agents are coming out even as Policy Agent 3.0 is all the rage. I'll add the links for the two following agents to my Documentation and Downloads page soon:

• Access Manager Policy Agent 2.2  for Apache Tomcat 6.0
• Access Manager Policy Agent 2.2 for Microsoft IIS 6.0 WithOutlook Web Access 2007/ SharePoint 2007
  

I recently updated my last entry, More About Configuring Policy Agent 3.0, saying that I would add an entry about the famadm utility. Yeah, so, that's what I'm doing now.

Much of this info comes from engineering folks: Dennis Seah, Hua Cui,  and Sean Brydon.

As I mentioned in the update to my previous entry, info about setting up the famadm command line utility is provided on this Wiki page. Sean added that info, and while it has a Policy Agent 3.0 slant to it, much of the beginning steps that he describes relates to FAM 8, too, at least instructions describing how to make the famadm utility available.

Normal Software Development:

OpenSSO is changing constantly, of course. Some changes even affect the famadm utility. Therefore, from  build 4 to 5 (build 5 isn't out as of yet), a few differences will exist. For example, access to agents has changed in the FAM Console. In build 4, you access agents from the Configuration tab. In build 5, you access agents the way it was done in Access Manager: In the Access Control tab, you select a realm. Then you can access agents. How does this relate to the famadm utility? In build 4, when issuing famadm to create or configure an agent, it was not required to list an agent's realm. Now it is required. You can use -e or --realm for the realm argument, as such:

famadm  update-agent --realm
famadm  update-agent -e

Simple Example: 

Here's the famadm command with the list-servers subcommand: 

famadm list-servers 
    

With the required options, this command lists all server instances. Here is some usage info for this command:

Usage:

famadm list-servers
    --adminid|-u
    --password-file|-f

Issued from the directory containing the famadm utility, the command might look like either of the following two examples:

[root@localhost]# ./famadm list-servers --adminid amadmin --password-file /tmp/testpwd

[root@localhost]# ./famadm list-servers -u amadmin -f /tmp/testpwd

A More-Involved Example:

What Dennis pointed out to me was that you can enter the subcommand name of the famadm command, such as update-agent. To which, the response will be a list of options. First, here's a complete command issued from the directory containing the famadm utility:

[root@localhost]# ./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f /tmp/testpwd -a "com.sun.identity.agents.config.locale=en_US"

Now, in the box below is the famadm command with the update-agent subcommand, also issued from the directory containing the famadm utility (notice that the options for this subcommand are provided and explained).

[root@localhost]# ./famadm update-agent Incorrect option(s), famadm  update-agent famadm update-agent --options [--global-options]     Update agent configuration. Usage: famadm update-agent     --realm|-e     --agentname|-b     --adminid|-u     --password-file|-f     [--set|-s]     [--attributevalues|-a]     [--datafile|-D] Global Options:     --locale, -l         Name of the locale to display the results.     --debug, -d         Run in debug mode. Results sent to the debug file.     --verbose, -v         Run in verbose mode. Results sent to standard output. Options:     --realm, -e         Name of realm.     --agentname, -b         Name of agent.     --adminid, -u         Administrator ID of running the command.     --password-file, -f         File name that contains password of administrator.     --set, -s         Set this flag to overwrite properties values.     --attributevalues, -a         properties e.g. homeaddress=here.     --datafile, -D         Name of file that contains properties.

Let's focus on the following usage info: 

 famadm update-agent
    --realm|-e
    --agentname|-b
    --adminid|-u
    --password-file|-f
    [--set|-s]
    [--attributevalues|-a]
    [--datafile|-D]

We can tell  that the update-agent subcommand requires the following arguments:

realm, agentname, adminid, password-file

The options bounded by square brackets are optional. However, you need to use either --attributevalues or --datafile to provide an attribute name and the corresponding value.

The following is an example of how to set the locale for a web agent by storing the property name and value in a data file:

[root@localhost]# ./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f /tmp/pwd -D /tmp/testproperty

where the testproperty datafile contains the following text:
com.sun.identity.agents.config.locale=en_US

Updated 05/09/08 - I got some comments from developer Charles Wesley about this blog entry. I concluded that I should add one more section to it. Therefore, I've added the following section about wildcards:

Wildcards and Attribute Values: A Word of Caution

When issuing the famadm command, if you include attribute values that contain wildcards (e.g. '*'), then the  associated attribute name/value pair should be enclosed in double quotes to avoid substitution by the shell. This applies when you use the -a (or --attributevalues)argument. This isn't necessary when you list the attributes in a data file and access them with the -D argument. The following example demonstrates the use of double quotes while setting a J2EE attribute (Not Enforced URIs).

EXAMPLE :
[root@localhost]# ./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f /tmp/testpwd -a "com.sun.identity.agents.config.notenforced.uri[0]=/exampledir/public/*"

Michael blogged about Policy Agent 3.0 property configuration in the following entry:

Policy Agent Configuration with Agent 99

I have a few things I can share in this area:

• Image of the Policy Agent 3.0 Local and Centralized Configuration Options
• FAM Command-Line Interface (CLI) Examples
• Policy Agent 3.0 Properties: Labels, Names, and Double Secret Other Stuff
  

This is all relatively new stuff; some stuff I mention is yet to be finalized. So um, uh, set your expectations accordingly.

Image of the Policy Agent 3.0 Local and Centralized Configuration Options

Since I just happened to take a snapshot of the Federated Access Manager (FAM) Console of the creation of an agent profile, I thought I'd share the image:

Looking at the image above, you can see that you have the option while creating the profile to set the configuration to local or centralized. 

FAM Command-Line Interface (CLI) Examples

There's a lot you can do with the CLI to configure agents. Here, I'm just focusing on configuring the agent properties.  By the way, to create the agent, the command starts as follows:famadm create-agent. However, The examples below are for updating an agent after it's created.

Updated 05/05/08 - I found that the examples that were here yesterday were inaccurate. The new examples below should be correct. I'll add an entry about using the command line to configure agents. There's already some good info on it here: http://wikis.sun.com/display/OpenSSO/famadmAgents

Example 1: Below is an example of how to use the CLI to change the Agent Locale.

./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f /tmp/testpwd -a "com.sun.identity.agents.config.locale=en_US"

Example 2: Below is an example of how to use the CLI to change the FAM Login URL

./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f /tmp/testpwd -a "com.sun.identity.agents.config.login.url=
http://amHost.example.com:8080/opensso/UI/Login"

Policy Agent 3.0 Properties: Labels, Names, and Double Secret Other Stuff

Policy Agent developer Sean Brydon said to me, "Why don't you put together a wiki page that lists all the 3.0 agent properties so people can add details whenever they want?" I'm putting  that sentence in quotes as if that's what he said word for word. And though I don't remember what he actually said, I think it's safe to say that that's not exactly what he said. I'm just seeing if he's going to sue me for misquoting him. So, I'm testing just how "open" this OpenSSO thing is.

Anyway, whatever he actually said, he must have been pretty convincing because I've been working on that wiki page. Do you want to see it? Well, even if you don't, here's the link:

http://wikis.sun.com/display/OpenSSO/agent3properties 

I'll keep working on it. I don't know when you'll look at it, if at all (I mean, after all, I don't even know who you are) but if it's around early May, 2008, there's probably lots that can still be done.

The End

P.S. While I am a big fan of Get Smart, I have nothing to say about Agent 99 at this time. Sorry about that Chief.

Most of the agents in the Policy Agent 2.2 software set have been updated to Policy Agent 2.2-01.

Policy Agent 2.2-01-Related Resources

• My "Sun Java System Access Manager Policy Agent 2.2 Documentation and Downloads" page.
  I maintain this page that lists docs and downloads on one page, so you don't need to go to the various locations where these items are located. You can quickly tell which agents have been updated.
  
• In the "Sun Java System Access Manager Policy Agent 2.2 Release Notes," the 2.2-01 update section.
  A thorough explanation of the 2.2-01 update is provided here.
  

Policy Agent 2.2-01: Summary

The 2.2-01 update is an accumulation of enhancements and fixes made in Policy Agent 2.2 since it was first released. Fixes and enhancements were made from time to time and released in what has been called hot patches. Some fixes were agent specific while other changes affected all web agents or all J2EE agents. Now all the hot patches are integrated into Policy Agent 2.2-01. In the 2.2-01 update section of the Release Notes, you'll find info about the key enhancements and fixes made. The following are a couple of the more extensive changes discussed:

• Web Agents: Extending the HTTP methods available for requests
  
• J2EE Agents: Enabling Access Manager Identities to Access the IBMWebSphere Administration Console
  

OpenSSO Policy Agent 2.2-01 Agents:

As you can see in my "Sun Java System Access Manager Policy Agent 2.2 Documentation and Downloads" page, agents created in the OpenSSO project, as also listed below, have not yet been updated to Policy Agent 2.2-01 yet, but they will be soon:

Web Agents:
Agent for Sun Java System Web Server 7.0
Agent for Apache HTTP Server 2.2

J2EE Agents:
Agent for Sun Java System Application Server 8.2/9.0/9.1
Agent for BEA WebLogic Server/Portal 10

Conclusion:

So now you know about 2.2-01 or at least you know how to get info about it. Next stop, Policy Agent 3.0.

You can find links for Sun Java System Access Manager Policy Agent 2.2 for Microsoft Internet Information Services 5.0, both the download and the document, on my Policy Agent 2.2 Documentation and Downloads page.

The agent has been out for a little while now. I updated my Policy Agent 2.2 Documentation and Downloads page a few days back. I'm only posting an entry about it now because my dog ate the first blog entry about it. That's my story and I'm sticking to it.

In the following blog entry, Policy Agent 2.2 With Access Manager 7.1, I compared Policy Agent 2.2 to marathon runner Derek Clayton because they both exemplify high endurance. Well, I have another similar comparison to make. This comparison has to do with Sun's Identity Management suite and Sun's attitude toward identity management in general.

First, let me give you a little Sun identity management background:

Sun Java Identity Manager continues to be the absolute power house in user provisioning: http://blogs.sun.com/ontherecord/entry/sun_positioned_in_leaders_quadrant

Moreover, Gartner has also just placed Sun in the Magic Quadrant for the web access management (WAM) market: Magic Quadrant for Web Access Management

That puts Sun in the leader's pack. However, with Federated Access Manager 8.0 coming out, including Policy Agent 3.0, Sun's is getting ready to break from the pack.

Okay, so given that background, if Sun's identity management suite were a runner, it would be this runner:

I'm talking about the leader in this photo. She's Paula Radcliffe, the British long distance runner. Her personal best in the marathon is the world record of 2 hours 15 minutes and 25 seconds. There are very few men in the U.S. today that could run that fast. The second fastest time by a women is more than three minutes slower than that.

Some years back, amongst the most elite, Paula was a middle of the pack runner. Her running form has even been criticized. She kind of bobbles her head when she runs. But she persevered. She analyzed everything about her diet and training and tried new things. Icing down her legs after a training run, weight training, physical therapy, shoes, clothing, you name it. She even looked at the bobble of her head before deciding not to tweak that particular aspect of her running form. Her improvement was slow and steady and she kept tweaking things here and there until she became best of the best. Still, she's had disappointments. She doesn't win every single race she enters. She was struggling during the 2004 Olympics and dropped out at around the 23 mile mark. Recently, she had a baby and tried to come back real quick but found that she had to take her time. She seems to be back in form, though, winning the New York Marathon in 2007. She'll be competing in the 2008 Olympics in Beijing. Her future is looking bright. So, yeah, Sun's identity management suite is a bit like that.

Sun's commitment to identity management has been clear to me in a visceral sense for years. However, I never could articulate that importance until about a year back. I was reading the white paper Positioning Federated Identity For The UK Government by Sun's very own Robin Wilton, when suddenly there it was:

Sun's vision and the role of identity

Sun is known for its original corporate vision that “the network is the computer”, a vision since supplemented with the idea of “everything of value connected to the network”. There is a strong technological dimension to Sun's vision statements - but they are also important for what they imply about identity, authentication, authorisation, access control, trust and privacy. The more we assume that everything of value is connected to the network, the more vital it is that identity, appropriate access and online trust form the foundations of online service provision.

I couldn't have said it better myself. And trust me, I tried. That's it. That's why Sun must succeed in the identity management space. I would say the importance of identity management to Sun is something along these lines:

By hook or by crook, through hell and high water, Sun absolutely, positively must ensure that the identity management available for Sun systems is top notch, best of breed, as good as it gets. Sun's very survival depends on it.

It's an attitude. I imagine that Paula Radcliffe feels driven in a similar fashion. Her very survival isn't at risk, and yet her status as the greatest female runner in the world is. So, in such a situation, you search for what works and you do it. For Sun, it means embracing open source and embracing non-Sun platforms, R&D, acquisitions, blood, sweat, and tears: experiment, tweak, pay attention, analyze, repeat. You don't win them all, but you always keep a can-win attitude, and you learn. Then you go back to the drawing board: experiment, tweak, pay attention, analyze, repeat.

When it comes to web access management, Sun has been very attentive to the market and is incorporating big changes in Federated Access Manager 8.0 and Policy Agent 3.0.

Daniel Raskin explained a great deal of this in two blog entries about the FAM 8 roadmap back in September:

• Federated Access Manager 8.0 -- The Overview (Part I)
• Federated Access Manager 8.0 -- The Features (Part II)

Especially since Access Manager and Federation Manager are being combined in FAM 8, there's a huge emphasis on simplifying the customer experience. I write Policy Agent documentation, and Policy Agent 3.0 is the new version of Policy Agent that coincides with FAM 8. The big, big thing here is that FAM 8 provides centralized agent management with Policy Agent 3.0. This is huge. Customers have had to manage agents one at a time in the deployment container. Still Sun has had a very competitive product. With centralized agent management, Sun is really charging forward. Just saying "centralized agent management" is not enough to explain all the effort going into the agents to make them simpler to manage in so many ways. In time, you will see many things about Policy Agent 3.0 to be happy about. For now, here are a couple links to help you monitor what's going on with Policy Agent 3.0:

• OpenSSO Wiki: Policy Agent 3.0 pages
• Search for Policy Agent 3.0 on the OpenSSO project site

That first link above provides a lot of info, including some installation information.

In the Paula Radcliffe analogy, at this time, Sun is running amongst the front runners of the elite pack and is starting to focus on key factors that will launch it out to the very front with room to spare. Therefore, I'd say that in the identity management space, Sun hasn't yet run it's 2 hour 15 minute and 25 second marathon, but it's coming up real soon. Just as I wouldn't bet against Paula Radcliffe in Beijing in 2008, I wouldn't bet against Sun in the identity management space, in fact all indications are that Sun's the endurance athlete to beat in this race.

If you have a comment or a question, docs.sun.com (DSC) gives you a direct link to the writers of Sun documentation.

To comment on a particular document, while looking at the document online (on DSC), click Send Comments (see "1" in the graphic below). This is the preferred method in most cases. However, for general comments, you can use the Submit panel at the bottom of the  DSC page (see "2" in the graphic below). In all cases, please be as specific and detailed in your comments as possible.

The information provided by DSC visitors is often quite useful to the writer and is very much appreciated. If you find that the documentation is incorrect or just confusing, please let us know. Currently, the process is not fully automated, so the author might not see the comment for a while.
   

 

What's spurring this blog entry is a couple of issues that have come up with Policy Agent 2.2 for Sun Java System Application Server 8.2/9.0/9.1 as such:

1. The title of this agent was just changed to include the 8.2 part. There were mixed messages out there about which agent to use for Sun Java System Application Server 8.2. Now it's cleared up. If you want to install Policy Agent 2.2 on Sun Java System Application Server 8.2, use Policy Agent 2.2 for Sun Java System Application Server 8.2/9.0/9.1.
2. Do not install the Application Server 8.2/9.0/9.1 agent and Access Manager on the same Application Server 8.2/9.0/9.1 instance.

The second point comes up from time to time in different ways. For example, it came up in this forum posting:

http://forum.java.sun.com/thread.jspa?forumID=760&threadID=5201914

Anyway, the documentation for this agent states that you cannot install this agent and Access Manager on the same Application Server 8.2/9.0/9.1 instance, as such:

http://docs.sun.com/app/docs/doc/820-2539/gbbir?a=view 

However, this point is often missed. For example, I'm assuming that this issue was missed when someone sent a query to the docs.sun.com website. The question was about the following property:

com.sun.identity.agents.config.location

The property allows a J2EE agent to coexist with Access Manager on the same application server. This option does not apply to Policy Agent 2.2 for Sun Java System Application Server 8.2/9.0/9.1. Therefore, the property is not mentioned in Sun Java System Access Manager Policy Agent 2.2 Guide for Sun Java System Application Server 8.2/9.0/9.1.

I bring this up here because this second point gets missed pretty often. I figure that somehow the documentation isn't clear enough. So, I want to add this info here to try to make it more clear.

By the way, I should say something about how you can send comments to us technical writers when you are looking at documents on docs.sun.com. The question that I talk about above about the com.sun.identity.agents.config.location property was sent directly to docs.sun.com and eventually forwarded to me. Okay, it's decided then. In my next entry, I'll talk about how you can get comments to the writer of a document that you are reading on docs.sun.com.

A lot has been happening with Sun Java System Access Manager Policy Agent these days. In fact, I've updated the following page to reflect some of those changes:

Sun Java System Access Manager Policy Agent 2.2 Documentation and Downloads

Key things that have happened are as follows:

A New Agent: 

IBM Webshere Application Server 6.1

New Platform Support for Existing Agents:

• SAP Enterprise Portal 6.0 and Web Application Server 6.40: AIX
• Apache HTTP Server 2.0.54/1.3.33: AIX and Windows
  

A Policy Agent 2.2 Update: 

Policy Agent 2.2-01 for web agents

 In the near future, I'll post more information about the agents. For example, I'll go into more detail about the 2.2-01 release. Also, I'll start talking about the next version of Policy Agent, Policy Agent 3.0.

docs.sun.com (dsc): A document repository barely alive. We can rebuild it. We have the technology. We can make it better than it was. Better...stronger...faster.

We can, we did! I say "we," even though I didn't have anything to do with it, just trying to show my community frame of mind.

Check out http://docs.sun.com and see if it isn't faster and more searchable than ever. If you're familiar with dsc, you know it has been slow and difficult to navigate and search. Then, for a short period of time, it got better. Then, it got worse again. Now, it's good again, great in fact.

I brought in a crack team of scientist to fix the problem. I say "I" even though I didn't have anything to do with it. I also say "brought in" even though nobody was brought in. As I understand it, after dsc was improved, a new problem quickly arose that was causing poor performance. The dsc folks investigated thoroughly, found, and then fixed the problem. I could tell you what the problem was, but then I'd have to bore you into a coma with the details. I'd also need to understand what they did. Suffice to say, look for documents on http://docs.sun.com and tell me if it isn't better than before.

You can find links for Sun Java System Access Manager Policy Agent 2.2 for Apache HTTP Server 2.2, both the download and the document, on my Policy Agent 2.2 Documentation and Downloads page.

This agent was developed through the OpenSSO project.

By the way, here's a link to the Apache HTTP Server Version 2.2 Documentation, brought to you by the Apache Software Foundation. I don't know. I happened to be out there looking at that site, so I thought, "Hey, why not include a link to that documentation?" It's just the kind of guy I am.

Sincerely,

Me