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

Hi John,
Question unrelated to this specific post.
I'm assuming you are keeping http://blogs.sun.com/JohnD/page/policyagent up to date.
Can you give me some information about the 2.2 tomcat 6 agent. In your table you note "1 These agents were developed as part of the OpenSSO project and are considered Policy Agent 2.2, not 2.2-01."
Does this mean that the source code for the agent is available? If so, where should I look to get that from?
I'm having terrible trouble getting the agent to work on tomcat 6.0.18 or 6.0.14. Have posted to the users@opensso.dv.java.net mailing list but to no avail.
Affraid I may have to delv into source.

Posted by Damien on October 01, 2008 at 04:19 PM PDT #

Damien:

I believe the source code is available. If not, it certainly give the impression that it is. I responded to an emal thread that you have been involved in to see if anyone can tell us if the code
is indeed available (see my message pasted below). Let's see if that gets a response.

By the way, I looked at the thread in the mail archives here:
https://opensso.dev.java.net/servlets/
BrowseList?listName=users&by=
date&from=2008-09-01&to=
2008-09-30&first=1&count=403

Anyone?

Is the source code for the agent is available?

By checking out the instructions at this link, I assume so:
https://opensso.dev.java.net/source/
browse/opensso/

Also, I was able to browse the Tomcat 6 agent source code here:
https://opensso.dev.java.net/source/
browse/opensso/products/
j2eeagents/tomcat/

Can someone verify if the Tomcat 6 source code is indeed available?

Damian left a comment on my blog and I looked around to see if I could figure it out, but
am still not 100% sure that this will work.

John D.

Posted by John Domenichini on October 02, 2008 at 01:54 AM PDT #

Hi john,

My problem is regarding working with sample application. Here when i am clicking on "Invoke a Servlet Protected by URL Policy" link then it is redirecting it to the login page of the access manager. But after entring username and password (chris/chris), it is not going anywhere. It keeps on processing.
I have also created the policy and subjects as specified in the readme file of the application.

Please give me some clarification on that.

Posted by Mohit on October 07, 2008 at 08:58 PM PDT #

Mohit:

Okay, so you're in troubleshooting mode. I've been there myself a few times. A few things could be wrong here.

The best mode of attack is to ask the OpenSSO community. I just talked about this in my blog entry: "OpenSSO: Wildcards and Handling Resources with Query Strings" at this URL:
http://blogs.sun.com/JohnD/entry/opensso_wildcards_and_handling_resources

In that entry, talk about the mailing list, users@opensso.dev.java.net, and how to sign up for it.

One possible problem is the build of the OpenSSO server and the Agent (which agent?). There are problems with some builds.

Another possible problem is that something went wrong during the installation. I describe such an issue I had when installing the agent in my blog entry "GlassFish Instructions: domain1 for OpenSSO, domain2 for Policy Agent." When I entered the URL for the OpenSSO server, I added a forward slash (/) at the end. That messed up everything, but I didn't know it until I deployed the sample app.

Anyway, these things can come out in a discussion, if you describe your scenario to that mailing list.

Hope this helps.

John

Posted by John Domenichini on October 08, 2008 at 03:23 AM PDT #

John,

I have subscribed to the mailing list as specified by you. I have also posted the same problem.
Well just for your info i am using opensso build 5 and policy agent 3.0 on Glassfish v2 UR2. I have also checked my installation which i don't think i have made any mistake.
Just let me know if there is any work around until i get proper solution of my problem.

Thanks

Posted by Mohit on October 09, 2008 at 01:58 PM PDT #

Mohit:
I saw your question on the mailing list.

I don't know of any workaround. I often end up reinstalling OpenSSO and the agent when I run into an issue that I can't fix. Otherwise, it requires looking at log files and such. Which is all good and fine, but one should know what one is looking for. So, you got stable builds or periodic builds and are you using GlassFish is the container for OpenSSO? If it's a periodic build, they're not as stable, the chances of that being the issue are relatively high. I've installed the same build before only to get the same problem because it was a build issue. I've also installed the same build before resulting in the problem going away, which implies that I made some error along the way. Even adding a space at the end of a response to a prompt during agent installation can cause problems.

I'm hopeful that someone will respond to you query. What they will probably do is run through a list of things that might have gone wrong and potential fixes. It might be that they'll just say try reinstalling OpenSSO and the agent again. It's often a lot simpler than trying to troubleshoot.

John D.

Posted by John Domenichini on October 10, 2008 at 12:56 AM PDT #

Hi Mohit,

maybe you are getting a Redirect Error like described here: http://wikis.sun.com/display/OpenSSO/J2EEAgentTrouble#J2EEAgentTrouble-redirecterrors

I was able to solve this problem after enabling crossdomain SSO.

Posted by Kapustos on December 07, 2008 at 09:26 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
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