Friday Oct 31, 2008

OpenSSO Enterprise Policy Agent 3.0: Processing Requests

I have included two images of flow charts in this blog entry that show how a request for a resource is processed: one image is web-agent specific and one is J2EE-agent specific.

These charts show the possible scenarios that can take place when an end user makes a request for a resource. Therefore, the end user points a browser to a URL. That URL is a resource, such as a JPEG image, HTML page, JSP page, etc. When an agent is configured to protect that resource ("protect" is not always the correct word, but the agent has a role to watch the resource anyway), it intervenes to varying degrees and checks the request. The situation might be that all requests are granted for that particular resource. Maybe then the request is logged and maybe it isn't logged. Hopefully, the flow charts reflect the key details.

Coming up with a flow chart that provides just the right level of detail is a tricky proposition: too much detail and the image is too complex; not enough detail and the image doesn't provide much useful info. Anyway, after getting much input from developers, this is what I came up with.



The flow chart that  follows illustrates how a request for a resource is handled by a web agent. Therefore, the web agent is protecting resources on a web server or web proxy server. The flow chart shows the processes the web agent goes through to protect such resources.

 How a Resource Request is Processed by a Web Agent

Flow chart of a single rescource request in web agents.


The flow chart that  follows illustrates how a request for a resource is handled by a J2EE agent. You can see that the J2EE security that is available in application servers (though J2EE agents often protect resources on portal severs, too) adds a layer of complexity to the chart. The J2EE agent flow chart also shows how the filter mode setting affects the processing of a request.

 How a Resource Request is Processed by a J2EE Agent

11/01/08: The flow chart in the link that follows was updated today. The "Yes" lines coming out of the top right side were not aligned properly. The problem has now been fixed. However, the print was too small and difficult to read. Therefore the image has been split into two (see below). It should be easier to read.

To see the two images combined as one, see the following: Single Image

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

11/06/08: The following two flow charts were just updated today. The original chart has been split into two to allow the text to be larger. Hopefully, it's easier to read this way.

J2EE agent: flow chart showing a request for a resource, PART A

J2EE agent: flow chart showing a request for a resource, PART B


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.

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

Simple Example: 

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

famadm list-servers 

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

Usage:

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

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

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

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

A More-Involved Example:

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

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

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

 
[root@localhost]# ./famadm update-agent
Incorrect option(s), famadm  update-agent


famadm update-agent --options [--global-options]
    Update agent configuration.

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

Global Options:
    --locale, -l
        Name of the locale to display the results.
    --debug, -d
        Run in debug mode. Results sent to the debug file.
    --verbose, -v
        Run in verbose mode. Results sent to standard output.

Options:
    --realm, -e
        Name of realm.
    --agentname, -b
        Name of agent.
    --adminid, -u
        Administrator ID of running the command.
    --password-file, -f
        File name that contains password of administrator.
    --set, -s
        Set this flag to overwrite properties values.
    --attributevalues, -a
        properties e.g. homeaddress=here.
    --datafile, -D
        Name of file that contains properties.

Let's focus on the following usage info: 

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


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

realm, agentname, adminid, password-file

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

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

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

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

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

Wildcards and Attribute Values: A Word of Caution

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

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

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: http://wikis.sun.com/display/OpenSSO/famadmAgents

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

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

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

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

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

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

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

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

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

The End

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

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

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

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

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

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.

About

What does this box do?

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
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