Monday Jul 21, 2008

How to Install GlassFish Then Policy Agent 3.0

This entry describes how to install GlassFish as a container for content to be protected by Policy Agent 3.0 (Agent for Application Server 9.0) on a Solaris 10 (SPARC) machine. I also provide the instructions for installing the agent and performing some preliminary agent configuration. These instructions are related to the instructions I already provided in the following entry:

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.

Also, in this blog, you can bring up a list of blog entries with instructions for this deployment. This deployment is all on one machine (on Solaris 10) and inlcudes OpenSSO server on Tomcat 6.x with the Application Server 9.0 agent on GlassFish server. This will probably include other configurations, too, such as deploying the sample application and more. Click the following link:
Blog entires related to the deployment: Tomcat for OpenSSO & GlassFish for GlassFish agent

The How-to Information I'm Providing

About Tomcat, GlassFish, OpenSSO (FAM 8.0), and Policy Agent 3.0:
  1. Installed Tomcat 6.x on Solaris 10 (SPARC) and then OpenSSO on top of that. See this blog entry.
  2. The blog entry (you're reading now) is about installing GlassFish on the same machine used for step 1 and then installing the GlassFish agent, a J2EE agent, which is also referred to as appserver_v9_agent.
  3. In a blog entry in the near future, I hope to describe more about how to set up the J2EE agent sample application. Actually, Sean Brydon has written up quite a bit about installing the agent and the sample application, see this link here, and for lots of details on installing the J2EE agent sample application, see this link here. The tasks Sean describes are on earlier builds of OpenSSO and the agent, but the concepts are clear.
All of the how-to info I'm providing is in reference to one machine. I've installed it all on one machine.
  • Tomcat 6.x is the J2EE container for OpenSSO
  • GlassFish is the J2EE container protected by the Sun Java System Application Server agent (the GlassFish agent)
I refer to the one machine in various ways, depending upon which server I'm focusing on at that moment. For example, you'll see all of the following:

  • http://AgentHost.domain:8090

Just know, that for my instructions, all the URLs are served from the same machine, even though the host name is shown differently.

To Install GlassFish

This task description explains how to install GlassFish as an eventual container for Policy Agent 3.0 (Agent for Application Server 9.0) on a Solaris SPARC machine. This is with the assumption that OpenSSO is already running on this machine on Tomcat 6.x as I described in the following entry:
  1. Set the JAVA_HOME or JRE_HOME variable.
    For my environment (using the Bourne shell a.k.a "sh" shell), I did the following:
    1. Issue the following command:
      # JRE_HOME=/usr/jdk/instances/jdk1.5.0
    2. Issue the following command:
      # export JRE_HOME
    3. Issue the following command:
      # env
      This allows you to ensure that the JRE_HOME variable is set in the list of environment variables.

  2. Make a directory for the GlassFish installation.
    For example, from the root directory:
    # mkdir pa3gf
    That directory means Policy Agent 3.0 for GlassFish.

  3. Using a browser, download glassfish-installer-v2ur2-b04-sunos.jar from
    to the pa3gf directory.

    I downloaded the GlassFish build listed above. However, more options for GlassFish builds are listed here:

  4. Using the command line, extract the file using: 
    # java -Xmx256m -jar
    A license agreements appears.

  5. Accept the agreement
    1. Scroll and read through the agreement (In a perfect a world at least).
    2. Click Accept.
    This creates a glassfish directory with everything inside.

  6. Change into the glassfish directory.

  7. (Conditional) If the GlassFish host has another server on it running on port 8080, change the GlassFish port number as described in the substeps that follow.

    I'm installing GlassFish to host the agent. I already have Tomcat 6.x installed on port 8080. By default Glassfish attempts to use port 8080. If 8080 is being used already, the GlassFish installation will not be complete.  Therefore, this task describes how to change the default port of 8080 to 8090.

    1. Open the setup.xml file with a text editor.
    2. Locate the following line:
      <property name="instance.port" value="8080"/>
    3. Change the port number to something else, such as 8090.
      I'm not sure what range of port numbers is acceptable for instance.port, but 8090 is definitely acceptable.

      If you wanted to change the GlassFish port number after the installation, you would not edit the setup.xml file but the domain.xml file. Here's an example location for that file:  /pa3gf/glassfish/domain1/config/domain.xml

  8. Run the two following commands: 
    • # chmod -R +x lib/ant/bin
    • # lib/ant/bin/ant -f setup.xml

  9. After a successful build, change to the glassfish/bin directory. For example:
    # cd

  10. Issue the following command:
    # ./asadmin start-domain domain1

  11. Using a browser, verify the server is running by accessing http://AgentHost.domain:8090.
    You should get a Server Running page.

    I'm referring to this server as AgentHost because it will host the GlassFish agent.

  12. Login to GlassFish as admin (PW: adminadmin) by accessing the console at https://AgentHost.domain:4848.

To Create an Agent Password File

The location of this file is required and will be prompted for by the agent installer.
  1. Create an ACSII text file for the agent profile. The following is an example
    of such a text file: /pa3gf/gfagentpw

    I combined steps one and two by creating the file (gfagentpw) and adding the password (agent123) in a single command as follows (issued from the root directory):

    # echo agent123>>pa3gf/gfagentpw

  2. Using a text editor, enter the appropriate password in clear text on the first line of the file.
  3. Secure the  password file appropriately, depending on the requirements of your deployment.

To Create the Agent Profile in the OpenSSO Console

When I create the agent, I won't choose the option for the agent installer to create the agent profile for me automatically (agentadmin --custom-install), so I need to do this task myself.
  1. Using a browser, log in to OpenSSO Console as amAdmin.
    For me, I'm using the OpenSSO instance that I installed on Tomcat 6.0, which  I discussed in the following entry:
    In that entry, I refer to that machine as follows:
    Since the Tomcat host is now also the OpenSSO host, I'll be referring to it as OpenssoHost.
    The following two examples demonstrate potential formatting for the URL of the login page:
  2. Select Access Control tab>realmname (such as opensso)>Agents>J2EE
  3. In the Agent section, click New.
  4. Fill in the fields as appropriate:

    Example Value
    Re-enter Password
    Server URL
    Agent URL
About the fields: Note the name and password you enter since you will need this info again. The password must be the same as the password in the agent password file. A centralized configuration is a key aspect to Policy Agent 3.0 and allows you to control the agent from the OpenSSO Console. For the Server URL, enter the info for the OpenSSO server. In this case, I'm using Tomcat 6.0, which  I discussed in the following entry: For the Agent URL, enter the info for the GlassFish server that you just installed with the port number for domain1, which for my scenario was port 8090.

To Install GlassFish Agent (appserver_v9_agent)

This task describes how to install the GlassFish agent, appserver_v9_agent on the GlassFish server.
  1. Download the Sun Java System Application Server 9 agent to the directory in which you want to unpack the agent binaries.

    I'm using nightly builds instead of "Stable Agent Builds," such as builds tested with OpenSSO V1 Build 4.5. For the agent, I wanted to use a June 29 build to match the date of the OpenSSO build I installed on Tomcat. However, that download was not working for me for some reason. So, instead, I got the June 30 download of this agent, at this location:
    Anyway, you can download a build with which you're comfortable. Look here:

    By the way, I'm downloading the agent in to the following directory: /pa3gf

  2. Unzip the zip file.
    For example:
    # unzip

  3. Stop the GlassFish domain with the following command (from the root directory):
    # glassfish/bin/asadmin stop-domain domain1
    If you don't shutdown the domain before creating the agent, it will modify files.

  4. Change to the directory that contains the agentadmin utility. For example:
    # cd /pa3gf/

  5. Set the permissions for the agentadmin utility. For example:
    # chmod 755 agentadmin

  6. Start the agent installation. For example:
    # ./agentadmin --install

    I used ./agentadmin --install instead of ./agentadmin --custom-install.

  7. Complete the installation as described in the substeps that follow:
    1. Continually press enter to accept the various parts of the license agreement.

    2. Enter yes to accept the complete agreement.
      You must then answer the agent installer prompts. Many of your responses will be responses you provided when you created the agent profile.

    3. Respond to the following prompt:
      Enter the Application Server Config Directory Path

      I responded with the following:

    4. Respond to the following prompt:
      Federated Access Manager URL:

      I responded with the name of the Tomcat server, on which I installed OpenSSO:

    5. Respond to the following prompt:
      Agent URL:

      I responded with the name of the GlassFish instance including the port for domain1:

    6. Respond to the following prompt:
      Enter the Agent Profile name:

      I responded with the following:

    7. Respond to the following prompt:
      Enter the path to the password file:

      I responded with the following:

      Then, a summary of your responses is displayed as such:

      Application Server Config Directory :
      Federated Access Manager URL :
      Agent URL :
      Agent Profile name : glassfishagent
      Agent Profile Password file name : /pa3gf/gfagentpw

      Verify your settings above and decide from the choices below.
      1. Continue with Installation
      2. Back to the last interaction
      3. Start Over
      4. Exit

    8. Respond to the following prompt by providing one of the options listed at the end of summary.
      Please make your selection [1}

      I responded with the following:

To Deploy Applications on GlassFish

There are a few ways to deploy applications on GlassFish. This task shows the method I used. I deployed two applications at the same time. The agentapp.war file is used for housekeeping tasks. The agentsample.ear file is the J2EE agent sample application, which gives you the opportunity to practice protecting an application with the agent. Therefore, you can create policies and perform other tasks that control access to the application.  I plan to add a blog entry in the future about using the sample application, so I've decided to deploy it now.

  1. Copy the agentapp.war file and the agentsample.ear file to the GlassFish autodeploy directory. For example, from the root directory, I issued the following commands:

    # cp /pa3gf/j2ee_agents/appserver_v9_agent/etc/agentapp.war /pa3gf/glassfish/domains/domain1/autodeploy

    # cp /pa3gf/j2ee_agents/appserver_v9_agent/sampleapp/dist/agentsample.ear  /pa3gf/glassfish/domains/domain1/autodeployGlassfish Console: Left Pane

  2. Start the GlassFish server with the appropriate command. For example I issued the following command (from the root directory):
    # pa3gf/glassfish/bin/asadmin start-domain domain1

    When the domain starts, the two applications will deploy.

  3. Verify that the Application Server is running and the two applications were deployed as described in the substeps that follow:
    1. Using a browser, access
    2. Log in with the proper credentials. For example:
      User name: admin
      Password: adminadmin

  4. In the left pane, click the arrows next to the following labels:
    • Enterprise Applications
    • Web Applications

    You should see the two applications you just deployed, the agentsample and the agentapp, as illustrated in the image to the right.

    Now things are set for you to experiment with the sample application, which is what I'd like to get into soon myself. Hopefully, I'll be blogging about my travails with the sample application soon.

    As I mentioned at the beginning of this entry, Sean Brydon has written up quite a bit about the J2EE sample applicaton, the quick example is here and the detailed example is here.

Thursday May 08, 2008

Federated Access Manager: famadm Command Line Utility

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

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:


famadm list-servers

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.

famadm update-agent

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.

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

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:

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

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

Sunday May 04, 2008

More About Configuring Policy Agent 3.0

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:

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:

Agent Profile

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:

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="

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: 

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.

Friday Feb 29, 2008

Identity Management, FAM 8, Policy Agent 3.0, and Glory

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:

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:

Paula Radcliffe, New York Marathon 2007

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:

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:

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.


What does this box do?


« February 2017