John Domenichini's Weblog

Be Confident

See how identity management can help you protect, store, verify, and share identity data.

» View Now

Links* (with an asterisk) in the column below are readable

MY BLOG STUFF

My Blog Pages

Policy Agent 2.2 Page*

My Blog Feeds & Such

My Atom Newsfeed*

My RSS Newsfeed*

My Blog Archives

« October 2009
Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Today

My Blog Search

My Technorati Stuff

Profile*
Sites That Link Here*

My Recent Blog Entries

My Blog-Related Links

My Blog Stats

Total # of blog entries: 93

Total # of comments: 139

Today's Page Hits: 138

NOT MY BLOG STUFF

Sun Blogs

Michael Teger*

Other Sun Writers and Such

+ Software Related

David Goldsmith*
R. Rajesh*

Wildcard Matching in OpenSSO

The OpenSSO Enterprise policy service supports policy definitions that use either of the two following wildcards:

These wildcards can be used in policy related situations. For example, when using the OpenSSO Enterprise Console or the ssoadm utility to create policies or when configuring the Policy Agent property to set the not-enforced list.

Caution - When issuing the ssoadm command, if you include values that contain wildcards (* or -*-), then the name/value pair should be enclosed in double quotes to avoid substitution by the shell.

For creating a policy, the following are feasible examples of the wildcards in use: http://agentHost:8090/agentsample/* and http://agentHost:8090/agentsample/example-*-/example.html.

For the not-enforced list, the following are feasible examples of the wildcards in use:
Web Agents:
http://agentHost:8090/agentsample.com/*.gif and http://agentHost:8090/agentsample/-*-/images

J2EE Agents:
/agentsample.com/*.gif and /agentsample.com/-*-/images

Note - A policy resource can have either the multi-level wildcard (*) or the one-level wildcard (-*-), but not both. Using both types of wildcards in the same policy resource is not supported.

The Multi-Level Wildcard: *

The following list summarizes the behavior of the multi-level wildcard (the asterisk, *):

Matches zero or more occurrences of any character except for the question mark (?).
Spans across multiple levels in a URL
Cannot be escaped. Therefore, the backslash character (\) or other characters cannot be used to escape the asterisk, as such \*.

The following examples show the multi-level wildcard character when used with the forward slash (/) as the delimiter character:

The asterisk (*) matches zero or more characters, except the question mark, in the resource name, including the forward slash (/). For example, ...B-example/* matches ...B-example/b/c/d, but doesn't match ...B-example/?
Multiple consecutive forward slash characters (/) do not match with a single forward slash character (/). For example, ...B-example/*/A-example doesn't match ...B-example/A-example.
Any number of trailing forward slash characters (/) are not recognized as part of the resource name. For example, ...B-example/ or ...B-example// are treated the same as ...B-example.

Table B-1 Examples of the Asterisk (*) as the Multi-Level Wildcard

Pattern	Matches	Does Not Match
`http://A-example.com:80/*`	`http://A-example.com:80` `http://A-example.com:80/` `http://A-example.com:80/index.html` `http://A-example.com:80/x.gif`	`http://B-example.com:80/` `http://A-example.com:8080/index.html` `http://A-example.com:80/a?b=1`
`http://A-example.com:80/*.html`	`http://A-example.com:80/index.html` `http://A-example.com:80/pub/ab.html` `http://A-example.com:80/pri/xy.html`	`http://A-example.com/index.html` `http://A-example.com:80/x.gif` `http://B-example.com/index.html`
`http://A-example.com:80/*/ab`	`http://A-example.com:80/pri/xy/ab/xy/ab` `http://A-example.com:80/xy/ab`	`http://A-example.com/ab` `http://A-example.com/ab.html` `http://B-example.com:80/ab`
`http://A-example.com:80/ab/*/de`	`http://A-example.com:80/ab/123/de` `http://A-example.com:80/ab/ab/de` `http://A-example.com:80/ab/de/ab/de` `http://A-example.com:80/ab//de`	`http://A-example.com:80/ab/de` `http://A-example.com:80/ab/de` `http://B-example.com:80/ab/de/ab/de`

Pattern

Matches

Does Not Match

http://A-example.com:80/*

http://A-example.com:80

http://A-example.com:80/

http://A-example.com:80/index.html

http://A-example.com:80/x.gif

http://B-example.com:80/

http://A-example.com:8080/index.html

http://A-example.com:80/a?b=1

http://A-example.com:80/*.html

http://A-example.com:80/index.html

http://A-example.com:80/pub/ab.html

http://A-example.com:80/pri/xy.html

http://A-example.com/index.html

http://A-example.com:80/x.gif

http://B-example.com/index.html

http://A-example.com:80/*/ab

http://A-example.com:80/pri/xy/ab/xy/ab

http://A-example.com:80/xy/ab

http://A-example.com/ab

http://A-example.com/ab.html

http://B-example.com:80/ab

http://A-example.com:80/ab/*/de

http://A-example.com:80/ab/123/de

http://A-example.com:80/ab/ab/de

http://A-example.com:80/ab/de/ab/de

http://A-example.com:80/ab//de

http://A-example.com:80/ab/de

http://B-example.com:80/ab/de/ab/de

The One-Level Wildcard: -*-

The one-level wildcard (-*-) matches only the defined level starting at the location of the one-level wildcard to the next delimiter boundary. The “defined level” refers to the area between delimiter boundaries. Many of the rules that apply to the multi—level wildcard also apply to the one-level wildcard.

The following list summarizes the behavior of hyphen-asterisk-hyphen (-*-) as a wildcard:

Matches zero or more occurrences of any character except for the forward slash and the question mark (?).
Does not span across multiple levels in a URL
Cannot be escaped. Therefore, the backslash character (\) or other characters cannot be used to escape the hyphen-asterisk-hyphen, as such \-*-.

The following examples show the one-level wildcard when used with the forward slash (/) as the delimiter character:

The one-level wildcard (-*-) matches zero or more characters (except for the forward slash and the question mark) in the resource name. For example, ...B-example/-*- doesn't match ...B-example/b/c/ or ...B-example/b?
Multiple consecutive forward slash characters (/) do not match with a single forward slash character (/). For example, ...B-example/-*-/A-example doesn't match ...B-example/A-example.
Any number of trailing forward slash characters (/) are not recognized as part of the resource name. For example, ...B-example/ or ...B-example// are treated the same as ...B-example.

Table B-2 Examples of the One—Level Wildcard (-*-)

Pattern	Matches	Does Not Match
`http://A-example.com:80/b/-*-`	`http://A-example.com:80/b` `http://A-example.com:80/b/` `http://A-example.com:80/b/cd/`	`http://A-example.com:80/b/c?d=e` `http://A-example.com:80/b/cd/e` `http://A-example.com:8080/b/`
`http://A-example.com:80/b/-*-/f`	`http://A-example.com:80/b/c/f` `http://A-example.com:80/b/cde/f`	`http://A-example.com:80/b/c/e/f` `http://A-example.com:80/f/`
`http://A-example.com:80/b/c-*-/f`	`http://A-example.com:80/b/cde/f` `http://A-example.com:80/b/cd/f` `http://A-example.com:80/b/c/f`	`http://A-example.com:80/b/c/e/f` `http://A-example.com:80/b/c/` `http://A-example.com:80/b/c/fg`

Pattern

Matches

Does Not Match

http://A-example.com:80/b/-*-

http://A-example.com:80/b

http://A-example.com:80/b/

http://A-example.com:80/b/cd/

http://A-example.com:80/b/c?d=e

http://A-example.com:80/b/cd/e

http://A-example.com:8080/b/

http://A-example.com:80/b/-*-/f

http://A-example.com:80/b/c/f

http://A-example.com:80/b/cde/f

http://A-example.com:80/b/c/e/f

http://A-example.com:80/f/

http://A-example.com:80/b/c-*-/f

http://A-example.com:80/b/cde/f

http://A-example.com:80/b/cd/f

http://A-example.com:80/b/c/f

http://A-example.com:80/b/c/e/f

http://A-example.com:80/b/c/

http://A-example.com:80/b/c/fg

Posted at 04:27PM Oct 05, 2008 by John Domenichini in Finding Info | Comments[5]
Tags used in this entry: opensso policyagent wildcard

Thursday Sep 11, 2008

Policy Agent 3.0: Learning About J2EE Agents By Using the Sample Application

This blog entry picks up where the last blog entry (GlassFish Instructions: domain1 for OpenSSO, domain 2 for Policy Agent) left off. This entry is all about setting up the sample application. The assumption is that you completed the tasks described in the previous entry.

YOU SHOULD INSTALL THE SAMPLE APPLICATION!!! I mean, unless you're extremely familiar with J2EE agents, you'll learn most effectively and efficiently by Installing the sample application and experimenting with it. By working with the sample application, you can figure out how it functions. It's invaluable.

Sample Application: To Configure Properties

The tasks described in this section provide a quick interaction with the sample application of the Glassfish agent (Policy Agent 3.0). Here, I'm describing how to interact rather simply with the sample application as opposed to the more detailed interaction suggested in the sample application readme.txt file. By the way, the readme.txt file is available in the sampleapp directory. For example: /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/sampleapp/readme.txt. You can learn a lot from the readme.txt file.

For example the readme.txt file explains that "The web.xml deployment descriptor has already been edited to include the Agent Filter." This is nice. For my scenario, the web.xml file of the sample application is available at this location: /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/sampleapp/etc/web.xml. I can now take a look at the web.xml file and see how the filter has been added and I can see how this file is configured in general. This can be very useful.

In a browser, log in to the OpenSSO Console as the amadmin user.
For my scenario, I logged in to this URL:
http://OpenssoHost.example.com:8080/opensso
Navigate to the agent for which you deployed the sample application:
For my scenario, I navigated to the following page:

Access Control tab>opensso>Agents>J2EE>glassfishagent

The Global tab is selected by default.

Click the Application tab to configure four properties as described in the substeps that follow.

At this point you will navigate within the Applicatin tab, setting various properties to experiment configuring the agent.

Configure the Login Form URI property as described:
1. Navigate to the property:
  Login Processing>Login Form URI (com.sun.identity.agents.config.login.form)
  
  The following page from the Policy Agent 3.0 Properties wiki describes this property: http://wikis.sun.com/display/OpenSSO/j2eeapplicationloginprocessing
2. In the field for Login Form URI property, enter the following value: /agentsample/authentication/login.html
3. Click Add.

Configure the Application Logout URI property as described:

Navigate to the property:
Logout Processing>Application Logout URI (com.sun.identity.agents.config.logout.uri)

The following page from the Policy Agent 3.0 Properties wiki describes this property: http://wikis.sun.com/display/OpenSSO/j2eeapplicationlogoutprocessing

In the fields for the Application Logout URI property, enter the following values:

Map Key	Corresponding Map Value
agentsample	/agentsample/logout

Click Add.

Configure the Resource Access Denied URI property as described:

Navigate to the property:
Access Denied URI Processing>Resource Access Denied URI (com.sun.identity.agents.config.access.denied.uri)

The following page from the Policy Agent 3.0 Properties wiki describes this property:
http://wikis.sun.com/display/OpenSSO/j2eeglobalgeneralresourceaccessdenieduridetails

In the fields for the Resource Access Denied URI property, enter the following values:
/agentsample/authentication/accessdenied.html

Map Key	Corresponding Map Value
agentsample	/agentsample/authentication/accessdenied.html

The accessdenied.html page is included with the sample application. In a real deployment, a custom accessdenied.html page would have to be created for your site, if desired.

Click Add.

Configure the Not Enforced URIs property as described:
1. Navigate to the property:
  Not Enforced URI Processing>Not Enforced URIs (com.sun.identity.agents.config.notenforced.uri)
  
  The following page from the Policy Agent 3.0 Properties wiki describes this property:
  http://wikis.sun.com/display/OpenSSO/j2eeapplicationnotenforceduriprocessing
2. In the field for the Not Enforced URIs property enter each of the following values one at a time and click Add after entering each value:
  /agentsample/public/*
  /agentsample/images/*
  /agentsample/styles/*
  /agentsample/index.html
  /agentsample/
  /agentsample
3. Scroll up as necessary to click Save.

(Optional) Click the Global tab if you would like to increase the debug logging level as described in the substeps that follow.

During agent deployment and testing, keeping the debug level at "message" can be quite useful. A variety of error and error-related messages are then logged to the debug log file. This debug level can be extremely valuable for troubleshooting purposes.
1. Navigate to the following property General>Agent Debug Level (com.iplanet.services.debug.level)
  
  The following page from the Policy Agent 3.0 Properties wiki describes this property:
  http://wikis.sun.com/display/OpenSSO/j2eeglobalgeneralagentdebuglevel
2. Select the "message" level.
3. Scroll up as necessary to click Save.

Sample Application: To Create Users and Groups

In the OpenSSO Console, navigate to the User subtab.

For my scenario, I am picking up where I left off in the last task. Therefore, I just clicked Save after changing configuration property settings, so I selected the following options to get to the User tab:
Back to Main Page>Subjects tab>User tab

Create a new user "chris" (all lower case letters) with a password "chris" as described in the substeps that follow:

Click New.

Fill in the fields on the New User page as illustrated in the table that follows:

New User: Field	Enter the Following:
ID	chris
FirstName:	chris
Last Name:	chris
Full Name:	chris
Password:	chris
Password (confirm):	chris
User Status:	Active

Click OK.

Notice that "chris" is now listed in the User list.
Click the Group tab.

Create two new groups, "manager" and "employee," as described in the substeps that follow:

By the way, I messed up here originally and used uppercase initial letters. Therefore, I put "Manager" and "Employee". Later my mistatke prevented "chris" from gaining access to some of the sample application pages. Hua Cui, my go-to agent developer for any such issues, figured it out and showed me a work around, which involved the following attribute: Privileged Attributes To Lower Case (com.sun.identity.agents.config.privileged.attribute.tolowercase). Anyway, for the preceding attribute, the attribute type "group" had to be changed to true. That corrected my error and access was granted to "chris" as expected.

Click New.

Fill in the ID field on the New Group page as illustrated in the table that follows:

New Group: Field	Enter the Following:
ID	manager

Click OK.
Click New.

Fill in the ID field on the New Group page as illustrated in the table that follows:

New Group: Field	Enter the Following:
ID	employee

Click OK.

Notice that "employee" and "manager" are now listed in the Group list.

Add user "chris" to the "employee" group and the "manager" group as described in the substeps that follow:
1. Click the User tab.
2. Click chris in the list of users.
3. Click the Group tab.
  
  The groups "employee" and "manager" are listed in the Available column.
4. Click Add ALL to move "employee" and "manager" from the Available column to the Selected column.
5. Click Save.

Sample Application: To Create Policies

The goal of this task is to create a policy for the sample application:
http://AgentHost.example.com:33053/agentsample/

In the OpenSSO Console, navigate to the Policies tab.
For my scenario, I am picking up where I left off in the last task. Therefore, I just clicked Save after adding "chris" to groups, so I selected the following options to get to the Policies tab:
Back to Subjects>Policies

Create a new policy by following the substeps shown:

In filling in this info, I mostly just took names, such as P1, that Sean Brydon used in his detailed write up of the sample application.

WARNING! If you don't click the OK button on the New Policy page, any new rules, subjects, conditions, and response providers you might have already created will be lost. They are not saved until the policy is saved.

Click New Policy.
In the Name field, in the General section, enter P1.

Create a new rule by following the substeps shown:

In the Rules section, click New.
For step 1 of 2, ensure that "URL Policy Agent (with resource name)" is selected.
Click Next.

For step 2 of 2, complete the page as shown in the table that follows:

New Rule Component	Perform the Following
Name	Enter: JSP Pages
Resource Name	Enter: http://`AgentHost`.example.com:33053/agentsample/*
Action: GET	Click GET with Allow chosen
Action: POST	Click POST with Allow chosen

Click Finish.

Create a new subject by following the substeps shown:

The goal is to assign the groups "employee" and "manager" to the subject.

In the Subjects section, click New.
For step 1 of 2, ensure that OpenSSO Identity Subject is selected.
Click Next.

For step 2 of 2, complete the page as indicated in the table that follows.

New Subject Component	Perform the Following
Name	Enter: S1
Exclusive	Nothing. Skip this.
Filter (Select identity type)	Select Group as the identity type (Do not need use the field to the right). Click Search.
Available -> Selected	Click Add All to move "employee" and "manager" from the Available column to the Selected column.

Click Finsih.

This brings you back to the New Policy Page.

Click OK to save the entire policy.

Working with the Sample Application

CAUTION! The sample application and the OpenSSO Console will definitely interfere with each other if you view them in the same browser. Therefore, don't! If you are going to view the Console andthe sample application on the same computer, either close the Console or use different browsers. For example, Firefox for the Console and Internet Explorer for the sample application.

Furthermore, things can get odd with the the sample application in terms of cookie expiration. You might need to logout, especially if you get an access denied page.

Logging Out of the Agent Sample Application

The logout page does not have to exist for you to log out of the sample application. You can type "logout" in the URL field after the string "agentsample/." For example, http://AgentHost.example.com:33053/agentsample/logout.

When the agent receives a request for the resource "...agentsample/logout," it invokes the logout feature. This logs the user out of the application. You can verify that the user is logged out by trying to access a protected page resource and seeing that you are again asked to login, indicating you have been logged out. An alternative way to verfiy logout is to go to the opensso UI console main page and click the Sessions tab which will list all active sessions and you will see that the user is no longer listed since you logged out of the aplication.

Using a browser, access the sample application.
For example, visit the appropriate URL, as such: http://AgentHost.example.com:33053/agentsample

If everything works out, you'll see a page such as illustrated by the following image:
Click URL Policy Enforcement in the left frame.
A page shows up with a link worded as such:
"Invoke a Servlet Protected by URL Policy".
Click the "Invoke a Servlet Protected by URL Policy" link.

The agent takes you to the OpenSSO login page.
Enter the credentials for Chris: chirs/chris.

If things go well, the browser presents a page with the following message:
Successful Invocation: Please Verify
Try the other two links (J2EE Declarative Security and J2EE Security API).
On those two pages, click the various links that start with the word "Invoke."

In each case, you should see the same success message:
Successful Invocation: Please Verify
Click Show HTTP Headers.

A table appears, such as the one below, showing header request information for the sample application.

Header Name	Header Value
Showing Request Information Including Headers, Cookies, and Attributes Request Method: GET Request URI: /agentsample/jsp/showHttpHeaders.jsp Request Protocol: HTTP/1.1 Request Scheme: http Request Server Name: AgentHost.example.com Request Server Port: 33053
host	`AgentHost`.example.com:33053
user-agent	Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.4) Gecko/20070622 Firefox/2.0.0.4
accept	text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
accept-language	en-us,en;q=0.5
accept-encoding	gzip,deflate
accept-charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
keep-alive	300
connection	keep-alive
referer	http://`AgentHost`.example.com:33053/agentsample/public/urlpolicy.html
cookie	JSESSIONID=b6eb2151444c60fee7b61605c215; s_vi=[CS]v1\|48B43B1200006FE8-A000B0400005553[CE]; amlbcookie=01; iPlanetDirectoryPro=AQIC5wM2LY4SfcxG/3VzZI+HWuNsJhQ5ESAh7OTM7qYv2uU=@AAJTSQACMDE=#
Request Attribute Name	Atribute Value
com.sun.enterprise.http.sessionTracker	org.apache.coyote.tomcat5.SessionTracker@1a9d205

Posted at 07:28PM Sep 11, 2008 by John Domenichini in Finding Info | Comments[7]
Tags used in this entry: requestinfo sampleapp

GlassFish Instructions: domain1 for OpenSSO, domain2 for Policy Agent

This blog entry explains how to install GlassFish to host both OpenSSO server and Policy Agent 3.0. I then get into a little about deploying the agent sample application. In the very next blog entry, I get into configuring and experimenting with the sample application.

This one entry includes various tasks. The deployment described involves two GlassFish domains: one for OpenSSO (between builds 5 and 6) and one for the GlassFish agent (Agent for Application Server 9.0). The instructions are all for a Solaris 10 SPARC machine.

I've covered some of this before in this blog. However, I was using older OpenSSO builds. Some instruction details have changed since then. Furthermore, the use of two domains on GlassFish is new. Also, the sample application details included in the next blog entry are new.

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.

To Install GlassFish

This task description explains how to install GlassFish as an eventual container for OpenSSO server and Policy Agent 3.0. This is all being performed on on a Solaris 10 SPARC machine. The objective is to deploy OpenSSO on GlassFish domain1. Then to create a second glassfish domain (domain2) and install Policy Agent 3.0 (Agent for Application Server 9.0).

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:
  # JAVA_HOME=/usr/jdk/instances/jdk1.5.0
2. Issue the following command:
  # export JAVA_HOME
3. Issue the following commnad:
  # env
  This allows you to ensure that the JRE_HOME variable is set in the list of environment variables.
Make a directory for the GlassFish installation.
For example, in the root directory:
# mkdir GF_OSSO_PA
That's my shorthand for GlassFish container for OpenSSO server and the Glassfish agent.
Using a browser, download glassfish-installer-v2ur2-b04-sunos.jar to the GlassFish installation directory you just created. As you know, I named it as follows: /GF_OSSO_PA

I downloaded the GlassFish build listed above. I got to that file and one will see other similar GlassFish builds by starting here:
https://glassfish.dev.java.net/public/downloadsindex.html
Which brought me here:
https://glassfish.dev.java.net/downloads/v2ur2-b04.html
This is the wording and such for the download I finally got:
Solaris SPARC Platform glassfish-installer-v2ur2-b04-sunos.jar, size 54M

You can navigate to the download or you can right click the link immediately above and choose the option that controls where the download is saved within your directory system.
Using the command line, extract the file using: # java -Xmx256m -jarglassfish-installer-v2ur2-b04-sunos.jarA license agreements appears.
Accept the agreement
1. Scroll and read through the agreement.
2. Click Accept.
This creates a glassfish directory with everything inside.
Change into the glassfish directory. For example:
# cd/GF_OSSO_PA/glassfish
Run the two following commands:
- # chmod -R +x lib/ant/bin
- # lib/ant/bin/ant -f setup.xml
After a successful build, change to the glassfish/bin directory. For example:# cd/GF_OSSO_PA/glassfish/bin
Issue the command to start domain1:
For example, I issued the following command:
./asadmin start-domain domain1
Using a browser, verify the server is running by accessing http://OpenSSOhost.example.com:8080.
You should get a Server Running page.

I'm referring to this host, which is using domain1, as OpenSSOhost because it will host the OpenSSO server.
Using a browser, login to domain1 of GlassFish as admin (PW: adminadmin) by accessing the console using a browser:
An example of the URL is as follows: http://OpenSSOhost.example.com:4848.

Notice that 4848 is the port for the console for domain1 of Glassfish. The console for other domains will have different port numbers.

Edit the domain.xml file of domain1 as described in the substeps that follow:

When Glassfish is the container for the OpenSSO server, the domain.xml file should be edited as described.

Change directories to the config directory of domain1.
For example:
# cd /GF_OSSO_PA/glassfish/domains/domain1/config
Using your text editor of choice, open the domain.xml file.

Change the following JVM options as shown in the table below:

Changes to Make	Lines Before Editing	Lines After Editing
"client" to "server"	<jvm-options>-client</jvm-options>	<jvm-options>-server</jvm-options>
"512 to "1024"	<jvm-options>-Xmx512m</jvm-options>	<jvm-options>-Xmx1024m</jvm-options>

To Create a Second GlassFish Domain

These instructions are necessary if you are going to install OpenSSO and the GlassFish agent on the same Glassfish server. You cannot install the two on the same domain, so you will need to create a second GlassFish domain.

Ensure that domain1 is running.

You can do this by ensuring that GlassFish is accessible in a browser.
For my scenario, I visited the follwing URL: http://OpenSSOhost.example.com:8080

With domain1 running, you ensure that domain2 won't be assigned the same port as domain1.
Issue the command to create domain2:
For example, I issued the following command:

# /GF_OSSO_PA/glassfish/bin/asadmin create-domain --adminport 6868 --user admin domain2

Notice that the port 6868 used in the command above is the port to use to log in to GlassFish server domain2 while port 4848 is the port to use to log in to GlasFish server domain1.

Enter adminadmin as the password for the various password prompts you receive.

After you provide all the passwords, a list of configuration information is displayed.
Note the port number for the HTTP instance.

You will need this port number when you create Agent for Application Server 9.0 (the Glassfish agent) Look for the line about the HTTP instance. For example:
Default port 8080 for HTTP Instance is in use. Using 33053
In such a case you would note 33053. You will need that port number (whatever, it might be) when you install the agent on domain2.
Start the second GlassFish domain:
For example, I issued the following command:

# /GF_OSSO_PA/glassfish/bin/asadmin start-domain domain2
Enter adminadmin as the password for the password prompt you receive.
Using a browser, verify that you have access to the GlassFish console for domain2 by logging in to domain2 using admin (PW: adminadmin):

An example of the URL is as follows: http://OpenSSOhost.example.com:6868.
Shutdown the second GlassFish domain:
For example, I issued the following command:

# /GF_OSSO_PA/glassfish/bin/asadmin stop-domain domain2If you don't shutdown the second domain before creating the agent (later on), it will modify files.
Shutdown the first GlassFish domain:
For example, I issued the following command:

# /GF_OSSO_PA/glassfish/bin/asadmin stop-domain domain1

To Install OpenSSO on GlassFish Domain1

These instructions involve downloading OpenSSO in the same directory where I downloaded GlassFish (GF_OSSO_PA). I use domain1 of the GlassFish server.

Change directories to the location you want to download the OpenSSO binaries.

I used the GF_OSSO_PA directory I created previously. For example, I issued the following command:
# cd /GF_OSSO_PA
Using a browser, download the OpenSSO binaries to the directory of your choice.
For my scenario, I downloaded the binaries to the following directory: GF_OSSO_PA

The general URL to start from is as follows:

https://opensso.dev.java.net/public/use/index.html

A more specific location on the above page, for periodic builds, is here:
https://opensso.dev.java.net/public/use/index.html#periodic

The above URL brings you to the table named Periodic OpenSSO and Client SDK Builds. You could navigate to that table and right click the "opensso.zip" link. Or you could just right click it here: "opensso.zip". Then you can choose the option that controls where the download is saved within your directory system.

At the time I performed this task, the latest build was September 10th. When I install the GlassFish agent (described later in this blog entry), I also use the September 10th build.

Be aware that there's a risk-reward relationship involved with using periodic builds. The reward is that you might be able to see the newest features and behaviors. The risk is that the chances of the build failing or acting oddly are greater than when you use a stable buld. At least, you know the September 10th build is stable enough to handle all the tasks described in this blog entry.

If you want to install the same build that I did (since you know it's relatively stable) but at a point in time in which the Sept 10th build is no longer available from the Periodic OpenSSO and Client SDK Builds table, then you can pick it up at this link: http://download.java.net/general/opensso/nightly/20080910.1/opensso/

You can go to that page and right click the openso.zip link or you can right click it here: opensso.zip. Then you can control which directory the file is downloaded to.
Unzip the opensso.zip file.
I used the following command:
# unzip opensso.zip

This creates an opensso directory. Therefore, for me the opensso directory was at the following location: /GF_OSSO_PA/opensso
Copy the opensso.war file from the distributed opensso files to the autodeploy directory of the GlassFish server domain1.
For example:
cp /GF_OSSO_PA/opensso/deployable-war/opensso.war /GF_OSSO_PA/glassfish/domains/domain1/autodeploy

A few ways exist to deploy the opensso.war file. The command above demonstrates the method I used.
Start domain1 of the GlassFish server.
For Example, I issued the following command:

# /GF_OSSO_PA/glassfish/bin/asadmin start-domain domain1

Starting GlassFish domain1 with the opensso.war file in the autodeploy directory deploys the opensso.war file.
Confirm that GlassFish domain1 has started and OpenSSO has deployed as described in the substeps that follow:

Use a browser to check that Glassfish domain 1 has started:
For example, in a browser window, go to the following location:
http://OpenSSOhost.example.com:8080/

If everything goes properly, you will see the message:
"Your Application Server is now running"
Add the string opensso to the URL in the browser window.
For example:
http://OpenSSOhost.example.com:8080/opensso

If everything goes properly, you will see the OpenSSO server page labeled Configuration Options.

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.

Click Create Default Configuration.
Enter the same password for both of the Default User Fields: Password and Confirm.
For example, admin123.

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://OpenSSOhost.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.
Enter the same password for both of the Default Agent Fields: Password and Confirm.
For example, agent123.
Ensure that this password is different from the one you just created in the step 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."
Click OK.

The configuration process continues for a couple of minutes and then shows a configuration complete message.
Click Proceed to Login.
This brings you to the login page, which is at a URL such as the following:
http://OpenSSOhost.example.com:8080/opensso/UI/Login

To Create an Agent Password File

The location of this file is required and will be prompted for by the agent installer.

Create an ACSII text file for the agent profile. The following is an example
of such a text file: /GF_OSSO_PA/gfagentpw

I combined steps one and two by creating the file (gfagentpw) and adding the password (agent456) in a single command as follows:

# echo agent456>>/GF_OSSO_PA/gfagentpw
(CONDITIONAL) If you didn't combine the creation of text and the creation of the file in one command, using a text editor, enter the appropriate pasword in clear text on the first line of the file.

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-isntall), so I need to do this task myself.

Using a browser, log in to OpenSSO Console as amAdmin.
For example:
http://OpenssoHost.example.com:8080/opensso
Select Access Control tab>realmname (such as Top Level Realm)>Agents>J2EE
In the Agent section, click New.

Fill in the fields as appropriate:

Field	Example Value
Name	glassfishagent
Password	agent456
Re-enter Password	agent456
Configuration	Centralized
Server URL	http://OpenssoHost.example.com:8080/opensso
Agent URL	http://`AgentHost`.example.com:33053/agentapp

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 (for example agent456). 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 GlassFish domain 1. For the Agent URL, enter the info for the GlassFish server that you just installed with the port number for domain2, which for my scenario was port 33053 as explained in the task described previously in this entry titled "To Create a Second GlassFish Domain."

To Install the GlassFish Agent on GlassFish Domain2

This task involves the installation of the GlassFish agent on the GlassFish server, domain2.

Download the Sun Java System Application Server 9 (the GlassFish) agent to the directory in which you want to uninstall the agent.

For my situation, I'm downloading the agent in to the following directory: /GF_OSSO_PA

Since I used the September 10 build for the OpenSSO download, I'll be using the same date for the GlassFish agent download. If you install the OpenSSO server and the agent on the same day, the "latest" directory for the two downloads will have the same date.

You can start form the following URL for the latest J2EE agent builds:
http://download.java.net/general/opensso/nightly/latest/j2eeagents/

If you want to go to that page, you can then right click the link "appserver_v9_agent_3.zip" in the table or you can right click the following link: appserver_v9_agent_3.zip. Then you can choose the option that controls where the download is saved within your directory ststem.

If you want to install the same build that I did but at a point in time in which the Sept 10th build is no longer available from the J2EE agent page listed above, then you can pick it up at this link: http://download.java.net/general/opensso/nightly/20080910.1/j2eeagents/

You can go to that page and right click the appserver_v9_agent_3.zip link or you can right click the following link: "appserver_v9_agent_3.zip." Then you can choose the option that controls which directory the file is downloaded to.
Unzip the zip file.
For example:
# unzip appserver_v9_agent_3.zip
(Conditional) Ensure that GlassFish domain1 is running.
During agent installation, the agent searches for the OpenSSO server. The installation is more complete if the OpenSSO server is running.

For example, you can check the GlassFish console (http://OpenssoHost.example.com:4848). If it is not accessible, start GlassFish domain1 (For example # /GF_OSSO_PA/glassfish/bin/asadmin start-domain domain1)

Change to the directory that contains the agentadmin utility. For example:
# cd /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/bin
Set the permissions for the agentadmin utility. For example:
# chmod 755 agentadmin
Start the agent installation. For example:
# ./agentadmin --install

I used ./agentadmin --install instead of ./agentadmin --custom-install.
Complete the installation as described in the substeps that follow:

Continually press enter to accept the various parts of the license agreement.
Enter yes to accept the complete agreement.
You must then answer the agent installer prompts. Many of your responses will be responsses you provided when you created the agent profile.
Respond to the following prompt:
Enter the Application Server Config Directory Path
[/opt/SUNWappserver/domains/domain1/config]:

I responded with the following:
/GF_OSSO_PA/glassfish/domains/domain2/config
Respond to the following prompt:
OpenSSO server URL:

I responded with the name of the GlassFish Server domain1, which is where I installed OpenSSO:
http://OpenssoHost.example.com:8080/opensso

I've messed up here before where I put a forward slash "/" after "opensso": That causes huge problems. Don't put anything after "opensso": not even a space.
Respond to the following prompt:
Agent URL:

I responded with the name of the GlassFish instance including the port for domain2:
http://AgentHost.example.com:33053/agentapp
Respond to the following prompt:
Enter the Agent Profile name:

I responded with the following:
glassfishagent
Respond to the following prompt:
Enter the path to the password file:

I responded with the following:
/GF_OSSO_PA/gfagentpw

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

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
Please make your selection [1]:
Choose the applicable option.

I responded by pressing Return to accept the default choice: "1. Continue with Installation"

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, and it required for the notification mechanism to function. 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 and then you can test those policies. I'll be configuring the sample application in the next task, so I decided to deploy it at the same time that I'm deploying the agent application.

Deploying the sample application (e.g agentsample.ear) the way I do below (without building my own sample application) is possible because the agentsample.ear file is already built for me with the assumption that I used the default realm, "opensso" when installing the OpenSSO server. Well, good, I really did use the "opensso" realm, so I didn't have to change the realm information and rebuild the sample application myself. By the way, such details are explained in the sample application readme.txt file:
(e.g. /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/sampleapp/readme.txt)

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

# cp /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/etc/agentapp.war /GF_OSSO_PA/glassfish/domains/domain2/autodeploy

# cp /GF_OSSO_PA/j2ee_agents/appserver_v9_agent/sampleapp/dist/agentsample.ear /GF_OSSO_PA/glassfish/domains/domain2/autodeploy
Start GlassFish domain2 (the domain on which the agent is installed) with the appropriate command. For example I issued the following command:
# /GF_OSSO_PA/glassfish/bin/asadmin start-domain domain2
Enter the master password.
For example:adminadmin
When the domain starts, the two applications will deploy.
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 http://GlassFishHost.example.com:6868
  
  Remember that because of the way I created domain2, port 6868 is the correct port for domain2.
2. Log in with the proper credentials. For example:
  User name: admin
  Password: adminadmin
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,

Sean Brydon has written up quite a bit about the J2EE sample applicaton, the quick example is here and the detailed example is here.

The very next blog entry (Policy Agent 3.0: Learning About J2EE Agents By Using the Sample Application) describes how to set up the sample application. It's real important and useful info. Really!!!

Posted at 07:02PM Sep 11, 2008 by John Domenichini in Finding Info | Comments[5]
Tags used in this entry: domain1 domain2 glassfish glassfishagent opensso openssoconsole policyagent sampleapp

Wednesday Jul 23, 2008

Policy Agent 3.0 Ease of Use

When it comes to OpenSSO, the idea of Centralized Agents is a big deal. That's one of the ease-of-use features that's coming with OpenSSO. There have been a lot of little niceties made along the way that make the centralization of the agents even easier for customers. As the OpenSSO builds continue, configuring the agents in the OpenSSO Console has become simpler (step by step) for customers.

If you have installed earlier builds along the way, you've seen some of the improvements. I have included a couple of screenshots of the OpenSSO Console, showing the Policy Agent property views. These properties are map constructs. A map property is a property where a value is mapped to a key. In earlier builds, you had to enter more complicated information in a field. Now, the more complicated stuff is handled behind the scenes. You just enter a map key in one field and it's value in the other.

Hopefully, the inline help gives you enough information to understand what to enter for the map key and value. The inline help has become more thorough also, build by build.

Furthermore, if you need more detailed info then is available in Help, you'll be able to find it as I continue to work on the Policy Agent 3.0 Properties wiki. For example, the J2EE agent property listed below, Agent Filter Mode, is pretty involved. However, there's a description on the wiki for it now: http://wikis.sun.com/display/OpenSSO/j2eeagentfiltermode

Such descriptions are a work in progress. They can be continually improved upon as various deployment scenarios bring up new questions about a property.

A Web Agent Map Property

A snapshot of a web agent map property

A J2EE Agent Map Property

A snapshot of a J2EE map property

The Agent Filter Mode property above is interesting because it highlights the global option, which applies to some J2EE map properties. Some J2EE map properties can apply to specific applications on the application server or globally to all the applications on the application server. The inline instructions above describe how to apply the property globally to all applications or individually to specific applications.

Posted at 02:25PM Jul 23, 2008 by John Domenichini in Finding Info | Comments[0]
Tags used in this entry: opensso openssoconsole policyagent properties propertieswiki

Supported Sun Access Manager Updates More Quickly: OpenSSO Express

Lots of people are abuzz today about OpenSSO Express and what it means to customers using Sun Access Manager:

Daniel Raskin: http://blogs.sun.com/raskin/entry/sun_announces_opensso_express
The Identity Management Buzz Blog: http://blogs.sun.com/idmbuzz/entry/announcing_sun_s_opensso_express
Michael Teger: http://blogs.sun.com/docteger/entry/here_comes_the_express_opensso
Rajesh R: http://blogs.sun.com/rajeshr/entry/sun_announces_opensso_express_support
The Aquarium Blog: http://blogs.sun.com/theaquarium/entry/opensso_express_sun_support_for

If you can't find enough info about OpenSSO Express in the links above, I'd imagine that such info just doesn't exist.

Posted at 11:38AM Jul 23, 2008 by John Domenichini in Finding Info | Comments[0]
Tags used in this entry: accessmanager opensso openssoexpress

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: http://blogs.sun.com/JohnD/entry/how_to_install_tomcat_6.

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:

Installed Tomcat 6.x on Solaris 10 (SPARC) and then OpenSSO on top of that. See this blog entry.
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.
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:

Tomcat:

http://TomcatHost.example.com:8080/
http://OpenssoHost.example.com:8080/opensso

GlassFish:

http://GlassFishHost.example.com:4848
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: http://blogs.sun.com/JohnD/entry/how_to_install_tomcat_6.

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.
Make a directory for the GlassFish installation.
For example, from the root directory:
# mkdir pa3gf
That directory means Policy Agent 3.0 for GlassFish.
Using a browser, download glassfish-installer-v2ur2-b04-sunos.jar from
http://www.java.net/download/javaee5/v2ur2/promoted/SunOS/glassfish-installer-v2ur2-b04-sunos-ml.jar
to the pa3gf directory.

I downloaded the GlassFish build listed above. However, more options for GlassFish builds are listed here:
https://glassfish.dev.java.net/public/downloadsindex.html
Using the command line, extract the file using: # java -Xmx256m -jarglassfish-installer-v2ur2-b04-sunos.jarA license agreements appears.
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.
Change into the glassfish directory.
(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
Run the two following commands:
- # chmod -R +x lib/ant/bin
- # lib/ant/bin/ant -f setup.xml
After a successful build, change to the glassfish/bin directory. For example:# cdpa3gf/glassfish/bin
Issue the following command:# ./asadmin start-domain domain1
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.
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.

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
Using a text editor, enter the appropriate password in clear text on the first line of the file.
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.

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: http://blogs.sun.com/JohnD/entry/how_to_install_tomcat_6.
In that entry, I refer to that machine as follows: http://TomcatHost.example.com:8080/
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:
- http://OpenssoHost.example.com:8080/opensso
- http://FamHost.example.com:8080/fam
Select Access Control tab>realmname (such as opensso)>Agents>J2EE
In the Agent section, click New.

Fill in the fields as appropriate:

Field	Example Value
Name	glassfishagent
Password	agent123
Re-enter Password	agent123
Configuration	Centralized
Server URL	http://OpenssoHost.example.com:8080/opensso
Agent URL	http://`AgentHost`.example.com:8090/agentapp

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: http://blogs.sun.com/JohnD/entry/how_to_install_tomcat_6. 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.

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:
http://download.java.net/general/opensso/nightly/20080630.1/j2eeagents/
Anyway, you can download a build with which you're comfortable. Look here:
https://opensso.dev.java.net/public/use/index.html

By the way, I'm downloading the agent in to the following directory: /pa3gf
Unzip the zip file.
For example:
# unzip appserver_v9_agent_3.zip
Stop the GlassFish domain with the following command (from the root directory):
# glassfish/bin/asadmin stop-domain domain1If you don't shutdown the domain before creating the agent, it will modify files.

Change to the directory that contains the agentadmin utility. For example:
# cd /pa3gf/j2ee_agents/appserver_v9_agent/bin
Set the permissions for the agentadmin utility. For example:
# chmod 755 agentadmin
Start the agent installation. For example:
# ./agentadmin --install

I used ./agentadmin --install instead of ./agentadmin --custom-install.
Complete the installation as described in the substeps that follow:

Continually press enter to accept the various parts of the license agreement.
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.
Respond to the following prompt:
Enter the Application Server Config Directory Path
[/opt/SUNWappserver/domains/domain1/config]:

I responded with the following:
/pa3gf/glassfish/domains/domain1/config
Respond to the following prompt:
Federated Access Manager URL:

I responded with the name of the Tomcat server, on which I installed OpenSSO:
http://OpenssoHost.example.com:8080/opensso
Respond to the following prompt:
Agent URL:

I responded with the name of the GlassFish instance including the port for domain1:
http://AgentHost.example.com:8090/agentapp
Respond to the following prompt:
Enter the Agent Profile name:

I responded with the following:
glassfishagent
Respond to the following prompt:
Enter the path to the password file:

I responded with the following:
/pa3gf/gfagentpw

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

-----------------------------------------------
SUMMARY OF YOUR RESPONSES
-----------------------------------------------
Application Server Config Directory :
/pa3gf/glassfish/domains/domain1/config
Federated Access Manager URL :
http://OpenssoHost.example.com:8080/opensso/
Agent URL : http://AgentHost.example.com:8090/agentapp
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
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:
1

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.

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/autodeploy
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.
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 http://GlassFishHost.example.com:4848
2. Log in with the proper credentials. For example:
  User name: admin
  Password: adminadmin
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.

Posted at 01:10PM Jul 21, 2008 by John Domenichini in Finding Info | Comments[3]
Tags used in this entry: agentapp.war agentprofile agentsample.ear fam glassfish opensso policyagent sampleapp tcossogfagent tomcat6

Wednesday Jul 16, 2008

Microsoft IIS 6.0 With Outlook Web Access 2007/SharePoint 2007, Access Manager Policy Agent 2.2 for

You can find links for Access Manager Policy Agent 2.2 for Microsoft Internet Information Services 6.0 With Outlook Web Access 2007/SharePoint 2007, both the download and the document, on my Policy Agent 2.2 Documentation and Downloads page. This agent is a 2.2-01 agent.

For a while now, the IIS 6.0 agent could be used to protect Microsoft Office SharePoint & Outlook Web Access, but previously that only applied to Outlook Web Access 2003/SharePoint 2003.

So we've all got this going for us anyway!

Posted at 04:28PM Jul 16, 2008 by John Domenichini in Finding Info | Comments[0]
Tags used in this entry: accessmanager documentation opensso policyagent

Tuesday Jul 15, 2008

OpenSSO Policy Agent Properties: What do you want to know?

Policy Agent 3.0 is coming out soon enough and the properties are still complicated. You can set them in the Federated Access Manager Console now, which is good, but it's still complicated. It's the details that are difficult to get. And yet, some times you just gotta have the details.

What Do You Want to Know About Agent Properties?

What would you like to see in terms of property descriptions? Yes, YOU! Please tell us what you need to know, what you want to know.

The property details need to be filled in, so let us know which properties you would like described. We might as well start providing details for properties that the community wants. More on this later (see Questions)

Goal of the Policy Agent 3.0 Wiki

Let me exaplain. In an effort to capture all the details that come in for Policy Agent properties starting with Policy Agent 3.0, I'm putting together the following wiki page:

Policy Agent 3.0 Property Page

I'm just getting this Policy Agent 3.0 properties wiki put together now. However, if you perform an Internet search (using Google or whatever) by a specific Policy Agent property name, the search results will probably include this wiki (and relatively high in the results, too) as such: "agent3properties - OpenSSO - wikis.sun.com." This wiki should soon become THE place to go for reference info on Policy Agent 3.0 properties.

Policy Agent developer, Sean Brydon, has been instrumental in getting this wiki going. The problem in the past has been that even when a property description seems clear, which they often are not, other details can come in later about how the property interacts with other agent properties, or how certain settings affect how the agent interacts with Federated Access Manager, or a myriad of other details.

Clearly, it would be best if the property descriptions could be living descriptions that can be updated by a variety of stakeholders, especially those right in there working with the properties. That is the type of structure I hope to provide with the agent property wiki.

This Wiki and Federated Access Manager Console: The Connection

By following the link to the Policy Agent 3.0 Property Page, you'll notice that the wiki lays out the Policy Agent 3.0 properties in the same manner they are presented in the Federated Access Manager Console. Below is a snapshot of the Console, specifically showing a view of a J2EE agent. The snapshot shows the first few J2EE agent properties in the Global tab. Those first few properties are all in the Profile category:

This is an image of the Federated Access Manager Console in a J2EE agent view

The table that follows shows how the Policy Agent wiki lists the properties in the following category (Notice that the Details links in the table are live):

J2EE agent > Global > Profile

Profile (Global J2EE agent properties)

Property Label	Property Name	Online Help	More Details
Group	N/A	Help	Details
Password	N/A	Help	Details
Password (confirm)	N/A	Help	Details
Status	N/A	Help	Details
Agent Notification URL	com.sun.identity.client.notification.url	Help	Details
Location of Agent Configuration Repository	N/A	Help	Details
Configuration Reload Interval	com.sun.identity.agents.config.load.interval	Help	Details
Agent Configuration Change Notification	com.sun.identity.agents.config.change.notification.enable	Help	Details

The table that follows shows how the Policy Agent wiki lists the properties in the following category (Notice that the Details links in the table are live):

Web agent > Global > Profile

Profile (Global web agent properties)

Property Label	Property Name	Online Help	More Details
Group	N/A	Help	Details
Password	N/A	Help	Details
Password (confirm)	N/A	Help	Details
Status	N/A	Help	Details
Location of Agent Configuration Repository	N/A	Help	Details
Agent Configuration Change Notification	com.sun.identity.agents.config.change.notification.enable	Help	Details
Enable Notifcations	com.sun.identity.agents.config.notification.enable	Help	Details
Agent Notifcation URL	com.sun.identity.client.notification.url	Help	Details
Agent Deploymet URI Prefix	com.sun.identity.agents.config.agenturi.prefix	Help	Details
Configuration Reload Interval	com.sun.identity.agents.config.polling.interval	Help	Details
Configuration Cleanup Interval	com.sun.identity.agents.config.cleanup.interval	Help	Details

The Details Links

I'd like to get comments from the OpenSSO community on the property descriptions. At this point, in the Policy Agent 3.0 wiki, not too many of the Details links are filled in. However, for both web agents and J2EE agents, I've filled in all the properties in the Profile category. In the properties wiki, you have to click the Details link and look at each property description one by one. That will probably suit folks who are looking up info on a specific property.

Since I'd like to get community feedback on the property descriptions, I've listed the properties for the Profile category in the table below, so you can see them all in one shot. I've copied the descriptions exactly as they are in the Details links and pasted them in the table. However, since the properties in the Profile category don't align perfectly between web agents and J2EE agents, I've moved the J2EE properties around slightly in the table, so they now align.

Here are some questions to consider when you look at the property descriptions and when you look at the Policy Agent properties wiki in general:

Which of the properties in the table below have descriptions that you think are lacking?
What type of info do you want for a given property?
Do you have a better suggestion for a property description?
Besides the Profile properties, which other properties would you like to see descriptions for first?
Do you have any comments about the structure and such of the Policy Agent Properties Wiki Page?:
http://wikis.sun.com/display/OpenSSO/agent3properties
Do you have any comments on the structure of the Details pages?

If you have any comments please leave them in this blog entry.

Web Agents	J2EE Agent
Property Label: Group Property Name: N/A Description: The "group" property is available starting with Sun Federated Access Manager Policy Agent 3.0. The property allows you to assign an individual web agent to a previously configured web agent group. The individual web agent can then inherit selected properties from the group.	Property Label: Group Property Name: N/A Description: The "group" property is available starting with Sun Federated Access Manager Policy Agent 3.0. The property allows you to assign an individual J2EE agent to a previously configured J2EE agent group. The individual J2EE agent can then inherit selected properties from the group.
Property Label: Password Property Name: N/A Description: The value for the "Password" property was set when the agent was created using the Federated Access Manager Console or the `famadm` utility. It was also the password that was in the agent profile password file when the `agentadmin` program was issued to install the agent. You can change the password at any time in the future.	Property Label: Password Property Name: N/A Description: The value for the "Password" property was set when the agent was created using the Federated Access Manager Console or the `famadm` utility. It was also the password that was in the agent profile password file when the `agentadmin` program was issued to install the agent. You can change the password at any time in the future.
Property Label: Password (confirm) Property Name: N/A Description: The value for the "Password(confirm)" property must match the "Password" property. If you change the "Password" property you must also change the "Password(confirm)" property.	Property Label: Password (confirm) Property Name: N/A Description: The value for the "Password(confirm)" property must match the "Password" property. If you change the "Password" property you must also change the "Password(confirm)" property.
Property Label: Status Property Name: N/A Description: This property is set to Active by default. When set to Active, the agent is able to authenticate to and communicate with Federated Access Manager. When set to Inactive, the agent is not able to authenticate to Federated Access Manager.	Property Label: Status Property Name: N/A Description: This property is set to Active by default. When set to Active, the agent is able to authenticate to and communicate with Federated Access Manager. When set to Inactive, the agent is not able to authenticate to Federated Access Manager.
Property Label: Location of Agent Configuration Repository Property Name: N/A Description: The value for this property is originally set when the agent profile is created. If desired, change the configuration location to whichever of the two options is available: centralized or local. The centralized location allows you to control the configuration in a centralized manner, such as from the Console. The local option is provided for backward compatibility purposes. If the local configuration option is selected, the agent will use its local configuration in the FAMAgentConfiguration.properites file in the agent installation directory. In addition, the Console will only display the following properties: Password , Password (confirmation) , and Status	Property Label: Location of Agent Configuration Repository Property Name: N/A Description: The value for this property is originally set when the agent profile is created. If desired, change the configuration location to whichever of the two options is available: centralized or local. The centralized location allows you to control the configuration in a centralized manner, such as from the Console. The local option is provided for backward compatibility purposes. If the local configuration option is selected, the agent will use its local configuration in the FAMAgentConfiguration.properites file in the agent installation directory. In addition, the Console will only display the following properties: Password , Password (confirmation) , and Status
Property Label: Agent Configuration Change Notification Property Name: com.sun.identity.agents.config.change.notification.enable Description: When this property is enabled, the agent receives notification messages from the Federated Access Manager server about configuration changes.	Property Label: Agent Configuration Change Notification Property Name: com.sun.identity.agents.config.change.notification.enable Description: When this property is enabled, the agent receives notification messages from the Federated Access Manager server about configuration changes.
Property Label: Enable Notifcations Property Name: com.sun.identity.agents.config.notification.enable Description: When this property is enabled, notifications help maintain the following agent caches: SSO, policy, and configuration.	N/A
Property Label: Agent Notifcation URL Property Name: com.sun.identity.client.notification.url Description: The value for this property is the URL used by the agent to register notification listeners.	Property Label: Agent Notification URL Property Name: com.sun.identity.client.notification.url Description: The value for this property is the URL used by the agent to register notification listeners.
Property Label: Agent Deploymet URI Prefix Property Name: com.sun.identity.agents.config.agenturi.prefix Description: The value for this property is the value of the Universal Resource Identifier (URI). The default value is `/amagent`.	N/A
Property Label: Configuration Reload Interval Property Name: com.sun.identity.agents.config.polling.interval Description: The value for this property is the interval in minutes to fetch the agent configuration from Federated Access Manager.	Property Label: Configuration Reload Interval Property Name: com.sun.identity.agents.config.load.interval Description: The value for this property is the interval in seconds between configuration reloads. Setting this property to `0` disables the hot-swap mechanism.
Property Label: Configuration Cleanup Interval Property Name: com.sun.identity.agents.config.cleanup.interval Description: The value for this property is the interval in minutes to cleanup old agent configuration entries.	N/A

Summary

That sums things up. If you ever have any questions about a property, ask me here. I'll try to get the answer, and if applicable, I'll add the information to the Policy Agent 3.0 properties wiki.

Posted at 07:00PM Jul 15, 2008 by John Domenichini in Finding Info | Comments[2]
Tags used in this entry: opensso openssoconsole pa3 policyagent properties propertieswiki

Sunday Jun 29, 2008

How to install Tomcat 6.x then launch and configure OpenSSO

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.

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

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:

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.
Create a directory for the Tomcat 6 container.
For example:
# mkdir Tomcat-base
Change directories into the newly created directory.
For example:
# cd Tomcat-base
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.
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/
Edit the following Tomcat file as shown in the substeps that follow:
/Tomcat-base/apache-tomcat-6.0.14/bin/catalina.sh

Open the catalina.sh file using your editor of choice.
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"
Save and close the file.

Start Tomcat as described in the substeps that follow.
This is just to check that everything is working as expected.

Change directories to the location of the Tomcat startup script.
For Example:
# cd /Tomcat-base/apache-tomcat-6.0.14/bin
Issue the start up command.
For example:
# ./startup.sh

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

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.
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
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
Start Tomcat as described in the substeps that follow.
Because the opensso.war file is in the Tomcat webapps directory, starting Tomcat deploys OpenSSO.

Change directories to the location of the Tomcat startup script.
For Example:
# cd /Tomcat-base/apache-tomcat-6.0.14/bin
Issue the start up command.
For example:
# ./startup.sh

Confirm that TomCat has started and OpenSSO has deployed as described in the substeps that follow:

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

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.

Click the link for Default Configuration.
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.
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."
Click OK.

The configuration process continues for a couple of minutes and then shows a configuration complete message.

Visit http://TomcatHost.example.com:8080/opensso again to confirm that you get the Sun Federated Access Manager login page.
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.

Posted at 07:12PM Jun 29, 2008 by John Domenichini in Finding Info | Comments[5]
Tags used in this entry: gz opensso tcossogfagent tomcat6

Friday Jun 27, 2008

Apache Tomcat 6.0, Access Manager Policy Agent 2.2 for

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.

Posted at 04:28PM Jun 27, 2008 by John Domenichini in Finding Info | Comments[2]
Tags used in this entry: accessmanager documentation opensso policyagent

View My StatCounter.com Stats

Wildcard Matching in OpenSSO

The Multi-Level Wildcard: *

Table B-1 Examples of the Asterisk (*) as the Multi-Level Wildcard

The One-Level Wildcard: -*-

Table B-2 Examples of the One—Level Wildcard (-*-)

Sample Application: To Configure Properties

Sample Application: To Create Users and Groups

Sample Application: To Create Policies

Working with the Sample Application

Showing Request Information Including Headers, Cookies, and Attributes

To Install GlassFish

To Create a Second GlassFish Domain

To Install OpenSSO on GlassFish Domain1

To Create an Agent Password File

To Create the Agent Profile in the OpenSSO Console

To Install the GlassFish Agent on GlassFish Domain2

To Deploy Applications on GlassFish

The How-to Information I'm Providing

To Install GlassFish

To Create an Agent Password File

To Create the Agent Profile in the OpenSSO Console

To Install GlassFish Agent (appserver_v9_agent)

To Deploy Applications on GlassFish

What Do You Want to Know About Agent Properties?

Goal of the Policy Agent 3.0 Wiki

This Wiki and Federated Access Manager Console: The Connection

The Details Links

Summary

To Install Tomcat 6.x

PRE-INSTALL INFO:

Tomcat 6.x

INSTALL STEPS:

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

PRE-INSTALL INFO:

INSTALL STEPS: