Thursday, May 14, 2009

Single Sign On (SSO) Server Configuration for Oracle 10gAS Application Server

This week, we continue our Fusion Middleware series with a discussion on how to configure and manage Oracle 10gAS Single Sign On (SSO) with Portal. Compared to the complex nature of OID and SSL, Single Sign On is fairly straight forward and simple to configure and administer. We will provide a summary of how SSO works within 10gAS and Portal and then some exercises to configure, administer and monitor its operations with Oracle 10gAS (10.1.2.0.2) on Linux platform.


How Does Single Sign On Work?

Single Sign On (SSO) is part of the Oracle 10gAS identity management (IdM) technology that is stored within the Oracle 10g Application Server database repository called the Infrastructure. The way it works is based on the concept of web browser cookies which are authenticated by the Oracle 10gAS server and reciprocated to partner and external applications on the end user web browser. Partner applications are internal web based applications such as Oracle 10g Portal, Forms and Reports within the Oracle 10gAS application server environment. In other words, users accessing applications within Oracle Application Server must be authenticated by the Oracle 10gAS Single Sign On Server. External applications are third party external web based applications that can be included in the 10gAS environment in terms of authentication via single sign on. Single Sign On (SSO) is based on the mod_osso module of the OHS (Oracle HTTP Server ie: Apache 1.3.x) within the Oracle 10gAS application server. Getting back to the difference between partner applications and external applications in terms of how SSO behaves is that external applications retain their usernames and passwords without delegating responsibility for authentication to the SSO server.

mod_osso and SSO


The mod_osso module is contained within the OHS (Oracle HTTP Server) and transmits simple header values to Oracle 10g Application Server applications as part of user validation and authentication procedures. These header values include the following:
-username
-userid GUID
- language information
- user DN (distinguished name) used with OID (Oracle Internet Directory)

The SSO server issues a challenge to the application and once the user and application have been authenticated, the redirect occurs back to the user browser which sets the SSO cookie in the user's browser with the authorization token. Now that we have given the summary on SSO concepts, lets examine how to setup, configure and administer a basic SSO environment with Oracle 10gAS (10.1.2.0.2) and Portal on Linux (OEL 5.3) platform.

Configure Single Sign On Server (SSO)


Single Sign On server (SSO) is composed of the OHS module mod_osso which provides a database access descriptor (DAD) that is stored as metadata configuration information in the Oracle 10gAS infrastructure database. SSO interfaces with OC4J (Oracle Container for Java) and OHS (Oracle HTTP Server or Oracle's implementation of Apache 1.3) to provide the mechanism for single user and password access to Portal and other Oracle 10g Application Server applications.

Single Sign On Concepts


Single Sign On (SSO) Server provides the mechanism for users to logon to Oracle Portal and Oracle Application Server applications by using a single username and password which is stored in the user's browser via a SSO cookie that has been authenticated against the SSO server. The components of Single Sign On (SSO) for Oracle 10gAS are the mod_osso module based in the OHS (Oracle HTTP Server) which is Oracle's version of the popular Apache 1.3 web server as well as metadata in the Oracle 10gAS infrastructure database.

How to Configure Single Sign On Server (SSO) for Oracle 10g Application Server


Our examples will user Oracle 10gAS (10.1.2.0.2) release on Linux (OEL 5.3) platform.
The following access point in Oracle 10g Application Server allows us to configure the SSO server.






In the below main screen for Oracle 10gAS we can view the main components for Single Sign On (SSO) Server:



Single Sign On Server provides many customization options for both partner and external applications. Partner applications are authenticated directly from within Oracle 10gAS while external applications have their own username and password authentication which are registered to the SSO server. Portal is a partner application for example. Now to view the status of the SSO server within the Oracle 10gAS infrastructure, we can navigate to the SSO server status:



From here we can monitor the status of SSO server operations including tracking any failed user logons authenticated against the Oracle 10gAS environment. Next, lets examine how to configure SSO Server settings for Oracle 10gAS.


This allows us to change settings for Single Sign On session duration as well as an additional session
policy setting that requires us to verify IP addresses for requests made to the SSO server.




For managing applications with Single Sign On (SSO) Server, we can access the link to Partner and External Applications as shown below.

For example, if we wish to modify configuration for exiting Portal applications, we can select the edit Partner application as follows.



Now the following options appear for Partner application configuration with SSO server.






Here we have a plethora of configuration options for our Portal based applications for Oracle 10g Application Server with SSO.
We can configure our URL settings as well as login timeframe details as well as application administrator account information. Now let's examine how to add and manage external applications with Single Sign On Server (SSO) for Oracle 10gAS.





Here we have many options for the URL and additional configuration settings for external applications with SSO.
Of particular interest to us is the login URL, username and password field name as well as the next subheading below
for Authentication Method for SSO with the external application. We have a few options here: POST, GET or BASIC AUTHENTICATION. Let's offer a brief explanation of these three methods below.

-POST allows data to be posted to the Single Sign On (SSO) server and submits login credentials within the body of the application form.

- GET presents the page request to the server and submits the login credentials in the application part of the URL

- BASIC AUTHENTICATION submits the login credentials within the application's
URL protected by HTTP basic authentication.

How to Access SSO Server from Oracle Portal


During installation for a midtier application server instance with Portal, Oracle automatically adds Portal as one of the
new partner applications for SSO. We can access SSO server from Portal as shown below.



Of note is to choose the second main section that shows Edit SSO Server Administration.

Single Sign On is simple to configure and administer. It is easier to manage and setup than the far more complex
items within Oracle Identity Manage such as OID and SSL which require far more steps. To monitor SSO server components from the operating system, we can use the OPMN (Oracle Process Monitor and Notification) facility. The command to obtain a status check for all of the Oracle 10gAS components is to run opmnctl status as shown in the following example.



Here we want to make sure that OC4J_SECURITY, OID, OC4J_Portal, and OID are in Alive status or SSO Server will not function correctly. We will provide future discussions on Oracle Fusion Middleware topics for Troubleshooting Oracle 10gAS, Webcache, Performance tuning and additional topics on Identity Management as well as coverage of the newest member of the Oracle Application Server family: Weblogic. Stay tuned!

Cheers,
Ben

1 comment:

Peter said...

Hi Ben! I was pleased to read your post - I'm pretty new to this, there are a few questions I've never seen answered (and I've been googling a while now...). Perhaps you can help to shed some light?

First, suppose a user is authenticated into SSO. The user now clicks a link to a partner appl. I assume that the appl will then check for a mod_osso cookie on the user's browser and, if it finds one, make a request to mod_osso to verify the cookie. Q: How exactly does mod_osso verify that the cookie is valid?

Second, I've seen references to mod_osso storing a cookie on OHS. is this only related to OracleAS version 9.x?

Lastly, how does mod_osso know a real cookie from a forgery? Similar to the first Q. Supposing someone created a cookie in memory, how would Oracle know the difference?

Thank you, I appreciate your help a lot.