Protecting Java EE Applications With OpenSSO Policy Agents, Part 2: Same-Domain SSO

Print-friendly Version

SSO is an access-control mechanism that enables users to log in and access multiple applications without having to log in again. With fewer login credentials to create, memorize, apply, and maintain, users and IT alike benefit from the savings in time and effort.

The three types of SSO are as follows:

• Same-domain SSO or simply SSO, which applies only to a single Domain Name System (DNS) domain.
  
  
• Cross-domain SSO (CDSSO), which applies to multiple domains within the same organization. With CDSSO in place, a user needs to log in only once and can then seamlessly access resources in different domains. When, after authentication, a user requests a resource in another domain, the CDSSO mechanism transparently transfers from the first domain to the intended destination an encrypted identity token affirming the user's authentication status. The destination domain then uses the token to build credentials for that user in its own cache. The token does not contain password information—hence another plus for security.
  
  
• Federation, which applies to domains across organizations, thanks to an industry standards-based method for sharing and managing identity data. By forming trust relationships, organizations can internally integrate applications from various departments and offer secure SSO services across the board. The same scenario works for services from external trusted partners. The standards in question include those developed by the Organization for the Advancement of Structured Information Standards (OASIS) and the Liberty Alliance Project.

This table lists as examples the domain names for the three types of SSO:

SSO Type	Policy Agent Host	OpenSSO Server Host
Same-domain SSO	agent1.sales.xyz.com	opensso1.sales.xyz.com
CDSSO	agent1.marketing.xyz.com	opensso1.sales.xyz.com
Federation	agent1.abc.com	opensso1.xyz.com

You can enforce SSO, CDSSO, and federation with Sun OpenSSO Enterprise 8.0. The procedure in this article describes how to achieve same-domain SSO only with that software.

To enforce same-domain SSO for the sample application in Part 1, first clear all the browser cookies and then do the following:

1. Log in to the OpenSSO Administration Console at http://my.test.domain.com:8080/opensso/UI/Login as amadmin and navigate to the configuration screen for the Policy Agent named myagentprofile. Click the Application tab. The screen shown in Figure 1 is displayed.
   
   
   

   Figure 1: Application Screen for myagentprofile
    
   
2. Click the Not Enforced URI Processing link for the related configuration screen.
   
   
3. Under Current Values, add these three values, one at a time: /mini-agentsample, /mini-agentsample/, and /mini-agentsample/index.jsp, as shown in Figure 2.
   
   
   

   Figure 2: Configuration Screen for Not Enforced URI Processing
    
   In most cases, you need list only one URL for a page. However, as specified in the application's web.xml file, the index.jsp is the default welcome page. That means that if someone goes to http://my.test.domain.com:6948/mini-agentsample, the Web container automatically directs that person to http://my.test.domain.com:6948/mini-agentsample/index.jsp. Given this special case, adding the other two URLs ensures that people can access the welcome page in all the standard ways.
   
   
4. Important: Click Save at the top.

This setting is hot-swappable: As soon as you've saved the settings, the Policy Agent is automatically notified so you need not restart its server for the new settings to take effect. By default, the notification capability for configuration changes is enabled. Take a look: Click the Global tab in the Policy Agent's configuration screen. The related setting is displayed under Profile.

Now test the access configurations. Again, first clear your browser cookies before following these steps:

1. Go to http://my.test.domain.com:6948/mini-agentsample/index.jsp.
   
   You can now access the welcome page without having to log in.
   
   
2. Click "Access the second protected page."
   
   You are redirected to the OpenSSO login screen.
   
   
3. Log in as Bob with the password secret.
   
   The protect_me.jsp page is displayed.
   
   Tip: If, after typing the login credentials and clicking Log In, you see a browser error message of HTTP Status 403 for a forbidden resource, verify that you have specified the agent filter mode of SSO_ONLY. Refer to the related step in Part 1.

Here's a simple demonstration of SSO with the sample application from Part 1.

Suppose your company's intranet offers multiple applications and you want all employees to be able to log in to one application and then access the others without having to log in again. Accomplishing that with OpenSSO and Policy Agents takes only a few steps:

1. Make a copy of the mini-agentsample.war file you obtained by unzipping the application in Part 1. Rename the duplicate another-mini-agentsample.war.
   
   
2. Deploy another-mini-agentsample.war by copying it to the autodeploy directory of the application domain in which you installed the Policy Agent.
   
   Since this is a copy of the application, its web.xml file has already been modified to refer to the Policy Agent filter.
   
   Also note that when you deploy a WAR file into the autodeploy directory, the WAR file name—in this case, another-mini-agentsample—appears as the application's context root so the application is at http://my.test.domain.com:6948/another-mini-agentsample. Correspondingly, its two pages are at http://my.test.domain.com:6948/another-mini-agentsample/index.jsp and http://my.test.domain.com:6948/another-mini-agentsample/protect_me.jsp.

Now, if you've already logged in to the original application, mini-agentsample, and can access its two pages, then you can access the same of another-mini-agentsample, with no other logins required. To confirm that you are accessing another-mini-agentsample, take a look at the URL, which contains the related context root for the protect_me.jsp page, as shown in Figure 3.

Figure 3: Protected Page of another-mini-agentsample

Specifying only certain resources, such as the welcome page, for public access lends versatility in the design of secure applications. It's a common practice well worth adopting.

In Part 3, the last part of this series, you'll learn how to restrict access of predefined resources to certain users only. Stay tuned.

• OpenSSO
  • Main page
  • Resource Center
  • Support: Sun OpenSSO Express
  
  
• Policy Agent download (with a deployable sample J2EE Web application)
  
  
• GlassFish application server
  
  
• Sun developer services
  • Support
  • Training and certification

We welcome your participation in our community. Please keep your comments civil and on point. You can optionally provide your email address to be notified of replies--your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.