|
Enterprise Identity Management
Fast Track to Single Sign-On
By David Jason Bennett
Learn how to fast-track your SSO development efforts with mod_osso and dynamic directives
If you're a developer interested in getting on the fast track to enabling your Web-based applications for single sign-on (SSO), you've come to the right place.
In this article, I will explain how to leverage a feature of the Oracle Application Server called mod_osso. After reading this article, you'll be able to SSO enable your browser-based applications in a matter of minutes. I will assume that you're familiar with the concept of SSO as well as with Java Servlets and J2EE.
SSO is an integral part of the Application Server and one of its most desirable features. The first release offered the SSOSDK, or Single Sign-On Software Developer's Kit. The SSOSDK provided PL/SQL- and Java-based APIs for SSO-enabling Web-based applications. The SSOSDK was a great tool, but the process of SSO-enabling an application was complex and required interaction between a developer, a DBA, and the application server administrator.
Oracle Application Server 10g offers an alternative method to developing SSO-enabled applications called mod_osso; mod_osso removed the complexity of SSO-enabling browser-based applications. It allows two basic methods for SSO-enabling an application: registering a global URL pattern and using dynamic directives. Let's examine both of these methods.
Thumbnail Sketch of mod_osso
Mod_osso is an Apache module that acts as the single point of contact with the SSO Server. In the past, SSO-enabling an application required that the application be registered with the SSO Server as a partner application. Mod_osso is already registered as a partner application (meaning that it delegates authentication to the SSO Server) and acts as an authentication proxy for other applications.
The mechanics of mod_osso are straightforward:
1. When a user request comes to the Web server from a user, mod_osso looks for its own encrypted session cookie.
2. If the cookie is found, the user has been authenticated and the request is served.
3. If the mod_osso cookie is not found, then the user is redirected to the SSO server and asked to authenticate.
4. If the login is successful, then a mod_osso cookie is set in the user's browser.
When the mod_osso cookie is set, the user can access any other SSO application without having to re-authenticate. Keep in mind, however, that authentication is only good for a single browser session.
Using A Registered URL Pattern
The most basic method of SSO-enabling a Web-based application using mod_osso is by registering a URL pattern with mod_osso. Any URL that falls within the registered URL pattern will become a protected URL. Again, the process of registering a URL with mod_osso is straightforward:
1. Register the URL pattern in the mod_osso.conf file located in $ORACLE_HOME/Apache/Apache/conf directory. The entry should look something like this:
<Location /myapp/*sec.do>
required valid-user
authType Basic
</Location>
Note: The recommended means of editing the mod_osso.conf file is through Oracle Enterprise Manager. Editing the file there will ensure that the changes will be saved and in synch with the infrastructure metadata repository.
2. Stop and re-start the Oracle HTTP Server so that the changes to the mod_osso.conf file are loaded.
3. Test the URL in a Web browser.
If all these steps are followed correctly, the first time a user makes a request for a URL that matches the registered pattern, the user will be redirected to the SSO Server login screen. After logging in, the user will be redirected to requested URL.
The main drawback to this method is that any URL that matches the pattern will require authentication. It is possible that some modules in an application will be public and not require authentication. The URL pattern in the mod_osso.conf example above suggests a way to segregate public and authenticated URL with a simple naming convention: All private modules will contain the string sec at the end of the module name; all other modules would be public. The greatest benefit to this method is that it requires no special coding to initiate authentication.
Obtaining user information from within the application is equally simple: The SSO Server places user-related information in the HTTP request headers. Among the most useful pieces of information stored in the request headers are user login id and user OID/LDAP Distinguished Name (DN). The following code sample illustrates how to access these values:
String username = request.getRemoteUser();
String user_oid_dn = request.getHeader("Osso-User-Dn");
Using Dynamic Directives
The most flexible method of using mod_osso is through dynamic directives. Dynamic directives consist of HTTP response headers coupled with a set special error codes. The special error codes let developers control the actions of the SSO Server.
Using dynamic directives, developers can write reusable components for initiating user authentication and user logout. Applications that use dynamic directives for initiating authentication and logout are not required to register a URL pattern with mod_osso. Dynamic directives are currently only supported for Java Servlets and JavaServer Pages.
The following is a list of common HTTP response header values and response error codes used to interact with the SSO Server:
- Osso-Paranoid — determines whether or the user should be forced to re-authenticate. Valid values are "true" and "false"; setting the value to "true" will force a user to re-authenticate even if the user has been authenticated by another SSO application. For example:
response.setHeader("Osso-Paranoid","true");).
- Osso-Return-Url — specifies where to redirect the user after successful login or logout. Valid values are any URL string. For example:
response.setHeader("Osso-Return-Url","/myapp/welcome.html");
- 499 — Response error code that when coupled with the value "Oracle SSO" indicates a request for authentication. For example:
response.sendError(499,"Oracle SSO);
470 — Response error code that when coupled with the value "Oracle SSO" indicates a request for logout of Single Sign-Off. For example:
response.sendError(470,"Oracle SSO");
The Java class in Listing 1 illustrates how dynamic directives might be used to create a reusable toolkit for SSO enabling applications.
Using a Custom URL Pattern with Dynamic Directives
It is still possible to use a URL pattern to segregate public and private modules without registering the pattern with mod_osso. The solution is to use a servlet filter that takes a custom URL pattern as a parameter. For example, the filter in Listing 2 sits in front of the controller (servlet) and looks for a custom URL pattern that indicates a request for a private module.
In this example, we obtained the specified URL pattern through a servlet filter parameter called urlparameter. Servlet filter parameters are defined in the web.xml file, a special J2EE configuration file that contains servlet configuration information specific to an application. Listing 3 shows an example of a web.xml file that maps our filter to a specific servlet called SSODynamicDirectiveServlet (see Listing 4.)
In the sample web.xml file, the URL pattern for a protected URL is set to sec.do. The servlet is mapped to URL pattern *.do, meaning that the protected module requests will have the form /<modulename>sec.do, while public modules will have the form /<modulename>.do. The first request for a module with the sec.do pattern will be redirected to SSO Server.
The approach of using a servlet filter works well when trying to integrate SSO with J2EE Frameworks such as Jakarta Struts or Oracle JHeadstart. Frameworks generally have a controller servlet that handles requests for screens/modules; placing a SSO filter in front of the controller servlet ensures that any request for a protected URL will be authenticated. If the filter is sufficiently generic, you can use it with multiple applications.
Steaming Ahead to SSO
Using the tools I've described here, you should be able to SSO-enable a new or existing application very quickly. Good luck and good coding.
Jason Bennett (David.Bennett@oracle.com) is a senior principal consultant with Oracle Government, Education, and Health Consulting specializing in Internet technologies.
| 
