Sun Java System Access Manager Policy Agents - Fetching Header/Response Attributes

<script type="text/javascript"> var sc_project=2888773; var sc_invisible=0; var sc_partition=29; var sc_security="0fc14962"; </script> <script type="text/javascript" src="http://www.statcounter.com/counter/counter_xhtml.js"></script>

1.Introduction

Web Applications protected by the Sun Java System Access Manager Policy Agents Version 2.2 can obtain the authenticated identity's attributes as well as the resource specific attributes by the following means

  • Set in as HTTP Header values

  • Set in the Browser Cookie as name value pairs.

In this part of article only the HTTP header option is discussed. The end application protected by the agents can obtain the authenticated identity's attributes as the HTTP header name value pairs in the following three ways:

  • Retrieve from authenticated identity's profile

  • Retrieve from authenticated identity's Session

  • Retrieve from policy resource response providers

2.0 Profile Attributes

To obtain the profile attributes as the HTTP header name value pairs, the following AMAgent.properties needs to be configured. Any change in the AMAgent.properties require a container restart in the web agents, In the J2EE agents if this property is not hot swappable then it requires a restart too.

2.1 Web Agents

In the web agents these attributes are retrieved over the PLL layer, The following two agents properties are to configured to fetch the user profile attributes

  • com.sun.am.policy.agents.config.profile.attribute.fetch.mode
  • com.sun.am.policy.agents.config.profile.attribute.map 

 The AMAgent.properties configuration should be made some thing like this for the web agents

Web Agents PRofile Attr fetc

In the browser these mapped values will show up headers in the following manner after the identity which access the protected resource has authenticated.

profile header

If there is no value found for the configured property then there is no HTTP header will appear for that particular mapping. In this particular example there is no HTTP_PROFILE_OU header because there is no value exists for the attribute ou in the profile of the authenticated user 'amadmin'. Irrespective of the filter mode these profile attributes are fetched and displayed in the browser header.

2.2 J2EE agents

In the J2EE agents these attributes are retrieved via the IdRepo APIs. To fetch the profile attributes as HTTP header attribute the following properties needs to be configured in the AMAgent.properties. You can use multiple properties as shown in the image below.

  • com.sun.identity.agents.config.profile.attribute.fetch.mode
  • com.sun.identity.agents.config.profile.attribute.mapping[attribute]

The AMAgent.properties configuration to fetch the profile attributes looks like this




Note that the syntax for the profile attribute mapping is different for the J2EE agents. These configured attributes are available at the protected application side for the authenticated user identities(only) as header attributes as shown in section 2.1

3.0 Session Attributes

The Access Manager Server can push the attributes to the end applications by setting them in the identity's authenticated SSO Token. But these attributes values are static until a session upgrade,session property change notification(if enabled at the server side) or a re authentication happens. Policy agents configuration properties can be configured in such a way certain session protected as well as the custom set properties can be be used by the protected application. These session attributes are directly retrieved from the session service of the Access Manager server.

3.1 Web Agents

Here is how the session attributes are mapped.

  • com.sun.am.policy.agents.config.session.attribute.fetch.mode
  • com.sun.am.policy.agents.config.session.attribute.map

3.2 J2EE Agents


For the J2EE agents there are different set of properties needs to be configured to retrieve the SSO Token Properties.

  •  com.sun.identity.agents.config.session.attribute.fetch.mode
  • com.sun.identity.agents.config.session.attribute.mapping[attr]

 



These session attributes are available at the protected application side in the form of HTTP headers. The following example screen dump is obtained using the web agents configuration.


4.0 Policy Response Provider Attributes

These attributes are delivered to the agents protected applications as part of the policy decision. These attributes have to be configured in the policy(Access Manager) server while creating the policy for the resource being protected. There are two kind of policy response provider attributes they are discussed in section 4.3 and 4.4

4.1 Web Agents

The attributes that needs to be configured at the protected application side are

 

  • com.sun.am.policy.agents.config.response.attribute.fetch.mode
  • com.sun.am.policy.agents.config.response.attribute.map



4.2 J2EE Agents


These response provider attributes are available to the protected application to only those authorized users of the resource where these attributes are defined. In the policy agents side following properties required to be configured. 

  • com.sun.identity.agents.config.response.attribute.fetch.mode
  • com.sun.identity.agents.config.response.attribute.mapping[polattr] = value



The corresponding policy definition would look like(only the response provider part is shown here)

 

Note that the attributes that are not mapped in the AMAgent.properties are also showing up in the HTTP headers example: WebLogicVersion and telephonenumber in the web agents but not in J2EE agents(atlease that is what I noticed in Weblogic 10 agents).

4.3 Static Policy Response Provider Attributes

These static attributes are configured in the policy as name value pairs in the format

attr=value1

multiple values can be configured in a new line separated list

attr1=value1

attr1=value2

This will show up in the header as HTTP_ATTR1=value1|value2

These attributes are available to only to those authorized users for the resource for which these attributes are configured. When the client ask for the policy decision for the protected resource, these attributes are also sent as part of the policy decision

4.4 Dynamic Policy Response Provider Attributes

These attributes are called dynamic due to the nature of them, they are basically the user profile attributes once they are changed in the underlying data store then automatically these changes are reflected to the protected application based on the notification/polling interval.

Whether these attributes are mapped in the agents configuration properties or not , these attributes name value pairs are available to the protected application in the policy response. If mapped to a specific name then they can be accessed through that name.

5.0 How to View the HTTP Headers

I have used the following CGI script to dump the relevant HTTP headers. This script prints only the headers that start with HTTP_ hence do not use this for generic headers dump. Copy and paste this script in to a fiel called headers.cgi and place this script in the cgi-bin location of your web server. Make sure this script has the execute permission for the CGI user.


#!/usr/bin/perl
print "Content-type: text/html\\n\\n";
for my $header ( sort keys %ENV) {
    next if ($header!~/\^HTTP/);
    print "$header : $ENV{$header}<BR>\\n";
}

You need to put this script's complete URL in the agents' not enforced list property to make it accessible without authentication and authorization. You can access this script by entering http://server.name:port/cgi-bin/headers.cgi which will print all the HTTP headers that start with HTTP_

Comments:

Post a Comment:
Comments are closed for this entry.
About

Indira Thangasamy, I manage the OpenSSO Quality engineering team.

Search

Archives
« April 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
   
       
Today