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.

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

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

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

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

    2. Configure the Application Logout URI property as described:

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

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

        Map Key Corresponding Map Value
        agentsample
        /agentsample/logout

      3. Click Add.

    3. Configure the Resource Access Denied URI property as described:

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

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

      3. Click Add.

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

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

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

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

    1. Click New.

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

  3. Click OK.

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

  4. Click the Group tab.

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

    1. Click New.

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

    3. Click OK.

    4. Click New.

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

    6. Click OK.

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

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

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

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

    1. Click New Policy.

    2. In the Name field, in the General section, enter P1.

    3. Create a new rule by following the substeps shown:

      1. In the Rules section, click New.

      2. For step 1 of 2, ensure that "URL Policy Agent (with resource name)" is selected.

      3. Click Next.

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

      5. Click Finish.

    4. Create a new subject by following the substeps shown:

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

      1. In the Subjects section, click New.

      2. For step 1 of 2, ensure that OpenSSO Identity Subject is selected.

      3. Click Next.

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

      5. Click Finsih.

        This brings you back to the New Policy Page.

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


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

    The sample applicataion
  2. 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".

  3. Click the  "Invoke a Servlet Protected by URL Policy" link.

    The agent  takes you to the OpenSSO login page.

  4. Enter the credentials for Chris: chirs/chris.

    If things go well, the browser presents a page with the following message:
    Successful Invocation: Please Verify


  5. Try the other two links (J2EE Declarative Security and J2EE Security API).

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

  7. Click Show HTTP Headers.

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

  8. 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
    Header Name Header Value
    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

    If you make changes to the agent attributes, you can see those changes reflected on the Show HTTP Headers page of the sample application. For example, you can see changes to the the Show HTTP Headers page if you change the properties in the Console in these sections: Profile Attributes Processing, Session Attributes Processing, and Response Attributes Processing.
About

What does this box do?

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