Monday Jan 12, 2009

Give Him OpenSSO Resource-based Authentication

Policy agents deployed to web containers and web proxy servers protect content from unauthorized intrusions. Access to this content (services, for example) are controlled through policies configured with OpenSSO. Here is a description of the interactions that occur when a policy agent interacts with OpenSSO.
  1. A policy agent intercepts the user's request and validates any authentication credentials contained within it. If the existing authentication level is insufficient, the OpenSSO Authentication Service will present a login page for an authentication upgrade. The login page prompts the user for the credentials appropriate to the configured module.
  2. The Authentication Service verifies that the user credentials are valid. For example, the LDAP authentication module verifies that the user name and password are the same as those stored in the LDAP identity data store. If other authentication modules are passed to the user (such as RADIUS or Certificate), the credentials are verified with the appropriately configured identity data store.
  3. Assuming the user's credentials are properly authenticated, the policy agent examines the policies assigned to the user.
  4. Based on the aggregate of the user's configured policies, the individual is either allowed or denied access to the resource.

NOTE: In this scenario, if the user attempts access to a web resource without authentication credentials, the agent redirects the user to the login page of the default authentication module. (Even if the resource is protected by a different authentication module, the user must first authenticate using the default authentication module.)

Because some customers require a scenario in which the user authenticates against a particular module based on the resource being accessed, the Gateway servlet provides resource-based authentication; there is no need for the user to authenticate to the default authentication module to access the protected web resource. When using the Gateway servlet:
  • A web resource can not be defined in more than one policy. For example, if abc.html is defined in a policy definition as requiring LDAP authentication, abc.html can not be defined in a second policy definition as requiring Certificate authentication.
  • You can use the level and scheme conditions only when defining policies that the servlet will examine.
Additionally, the Gateway servlet does not work across internet domains. Use the following list to configure your deployment to use the Gateway Servlet.
  1. Configuring the Web Container
  2. Configuring OpenSSO
  3. Configuring the Policy Agent
  4. Testing the Servlet
Configuring the Web Container

Generically speaking, you must ensure the following configurations on your web container. Check your container's documentation for information on how to do them.
  1. Check that the following certificates are installed:

    • A certificate for the server (Server-Cert).
    • A certificate for the trusted Certificate Authority.
  2. Add a listen socket for simple Secure Sockets Layer (SSL) and one for SSL client authentication.
  3. Ensure that the listener port configuration requires SSL for client authentication.
Configuring OpenSSO

  1. Log in to the OpenSSO console as the administrator.
  2. Click the Configuration tab and the Authentication tab under it.
  3. Click the Certificate Service Name link.
  4. Enable Match Certificate in LDAP by checking the box.
  5. Select Subject UID as the value for Certificate Field Used to Access User Profile.
  6. Enter 54430 as a value for SSL Port Number.
    This port number must match the port number used for the web container's SSL client authentication listener port in the previous procedure.
  7. Type 2 as the value for the Authentication Level attribute.
    The value used must be greater that the level defined for LDAP authentication.
  8. Click Save.
  9. Click Back to Service Configuration.
  10. Under the appropriate realm, add policies for three URL resources:

    1. policy1 has a condition of LDAP authentication only for http://agent-machine.domain/banner.html.
    2. policy2 has a condition of Cert authentication only for http://agent-machine.domain/banner2.html.
    3. policy3 has a condition of LDAP authentication and a level of Certificate authentication for http://agent-machine.domain/banner3.html.
See the OpenSSO Enterprise 8.0 Administration Guide for the official documentation on configuring OpenSSO Enterprise 8.0 for resource-based authentication.

Configuring the Policy Agent

  1. Go to the installation directory for the agent protecting the resource on the web container host machine. For example, on Application Server, change to AppSvr-Directory/agents/j2ee_agents/appserver_v9_agent/Agent_001/config/.
  2. Change the value for com.sun.am.policy.am.loginURL from http://machine-name.domain:port/opensso/UI/Login to http://machine-name.domain:port/opensso/gateway in OpenSSOAgentBootstrap.properties. It is the only change to the policy agent configuration.
Testing the Servlet

After these configurations, the test results are:

  • Access to resource A is permitted only after successful LDAP authentication.
  • Access to resource B is permitted only after successful Certificate-based authentication.
  • Access to resource C is permitted only after both successful LDAP and Certificate-based authentication.

Now that you've configured and tested resource-based authentication, the Shangri-Las are gonna give you a great big kiss with Give Him a Great Big Kiss. I was reminded of this song when it was used in a movie I saw this weekend called Stonewall, an account of the Stonewall riots of 1969. Worth checking out!

Thursday Sep 25, 2008

Are You Ready for OpenSSO Deployment 1?

Hi all. I'm still around but haven't had the time to blog as regularly as I'd (and hopefully you'd) like. Come November after the release of OpenSSO Enterprise 8.0, I will have more blog entries so stay tuned.

In the meantime, here is the Early Access edition of the Sun OpenSSO Enterprise 8.0 Deployment 1: Single Sign-on with Load Balancing and Failover. The book contains the procedures to implement, configure and test a full OpenSSO deployment for the purpose of single sign-on.

See comments below for UPDATES since this posting.

Key features of Deployment 1 include:
  • Installing and configuring Directory Server as a user data store.
  • Installing J2EE and web policy agents on protected resources.
  • Installing and configuring OpenSSO instances to run as a non-root user.
  • Configuring load balancers for session failover and high performance.
  • Configuring the deployment for system failover, ensuring that when one instance of OpenSSO Enterprise goes down, requests are redirected to the second instance.
  • Configuring components (including OpenSSO and Directory Server, the Distributed Authentication User Interface, and policy agents) as redundant to achieve high availability.
  • Configuring for Secure Sockets Layer (SSL) communications to the OpenSSO load balancer, to the Distributed Authentication User Interface load balancer, and to the Directory Server load balancer.
So check it out. You can also see the complete set of Early Access documentation for OpenSSO Enterprise 8.0. Now is the time to air your thoughts.

Thanks to Sun engineer Anant for his work on the book. Because of it, this book is an invaluable tool for understanding and keystroking an OpenSSO deployment.

And whether you are ready or not, Bucks Fizz certainly is. Are You Ready is the title song of their second album. Not sure if it's Jay or Cheryl wearing the diaper but it's quite an 80s sight!

Tuesday Mar 04, 2008

Wildcard Matches in Policy Agents

A comment was left in yesterday's entry on policy logic concerning the lack of consistency in how the different policy agents treat the wildcard. Now I am not an agent expert but I did manage to gather some information for Mr. Robinson that, I hope, helps to shed some light on how the wildcard is used by agents.

The Policy Service in OpenSSO supports policy definitions using an asterisk (\*) as the wildcard. Only \* is supported as a wildcard and it can not be escaped as in \\\*.

A \* :

  • matches zero or more occurrences of any character.
  • spans across multiple levels in a URL.

The following matching rules assume (rightfully so) the wildcard character is \* and the delimiter character is /.

  1. \* matches zero or more characters, including /, in the resource name.
  2. \* matches one or more characters, including /, if the \* appears at the end of the resource name and it is immediately preceded by a /. For example, abc/\* doesn't match abc.
  3. Multiple consecutive / characters don't match with a single /. For example, abc/\*/xyz doesn't match abc/xyz.
  4. For purposes of comparison, trailing / characters will not be considered as part of the resource name. For example, abc/ or abc// will be treated the same as abc.

Here are some examples:

Pattern Matches Doesn't Match
http://xyz.sun.com:80/\* http://xyz.sun.com:80/
http://xyz.sun.com:80/index.html
http://xyz.sun.com:80/x.gif
http://abc.sun.com:80/
http://xyz.sun.com/index.html
http://xyz.sun.com:8080/index.html
http://xyz.sun.com:80/\*.html http://xyz.sun.com:80/index.html
http://xyz.sun.com:80/public/abc.html
http://xyz.sun.com:80/private/xyz.html
http://xyz.sun.com/index.html
http://xyz.sun.com:80/x.gif
http://abc.sun.com/index.html
http://xyz.sun.com:80/\*/abc http://xyz.sun.com:80/private/xyz/abc/xyz/abc
http://xyz.sun.com:80/xyz/abc
http://xyz.sun.com/abc
http://xyz.sun.com/abc.html
http://abc.sun.com:80/abc
http://xyz.sun.com:80/abc/\*/def http://xyz.sun.com:80/abc/123/def
http://xyz.sun.com:80/abc/abc/def
http://xyz.sun.com:80/abc/def/abc/def
http://xyz.sun.com:80/abc/def
http://xyz.sun.com:80/abc//def

And while we're on the subject of wild things, think of X, the seminal punk band of all time. The song in this video isn't one they wrote (for that you'd have to check out Johnny Hit and Run Paulene, Nausea or Los Angeles) but it does segue nicely. Here's X covering The Trogg's (not Tone-Loc's) Wild Thing. And that's Chuck Berry on stage at the video's end - a wild thing in his own right.

UPDATE: For more information on policy logic and wildcards see the following entries:

About

docteger

Search

Categories
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