Single Sign-On (SSO) Oracle Application Server Tips by Burleson Consulting

Single Sign-On (SSO) provides that capability to have a user provide his credentials once and then to automatically authenticate him as he switches between applications.  This keeps the user from having to continuously re-enter his password as he switches between applications.  The first time a user enters his username/password (or other credentials), SSO creates an encrypted cookie that contains the identity information.  When the user changes applications, the new application uses the cookie to authenticate the user and retrieve his authorizations.  The user moves from one application to another without having to reenter is username and password.  When the user is finished, he can logout of SSO and it will log him out of all SSO partner applications.  We have already seen this when we logged out of the OID Self Service Console.  Figure 12-10 shows SSO logging me out after I selected the logout option in SSC.

Figure 10: Single Sign-On Logout page

If you spent some time looking around the Self Service Console you may have run into another feature of SSO, time limits.  The encrypted cookie SSO created when you log in has a time stamp and is only valid during that time.  If a user logs off without logging out of SSO, when he returns the cookie will be invalid and he will be required to re-login before he is authenticated.

Since SSO uses encrypted cookies to identify a user after he logs on, Oracle?s HTTP Server (OHS) is a key component.  OHS uses a module called mod_osso to handle SSO actions.  Mod_osso is used to integrate SSO transparently into an application, accepting request for authentication and providing the appropriate HEADER parameters.  SSO support is also built into Oracle?s Container for Java, OC4J, using the SSO software development kit however this is for backward compatibility with earlier versions of Oracle?s application server and is deprecated in 10g.  SSO itself is an application that runs in the infrastructure tier, handling authentication for both partner and external applications.

Partner Applications

A partner application runs in Oracle Application Server 10g and implements SSO to authenticate a user through mod_osso or the SSO SDK.  The application must identify the users privileges within the application but must also integrate with SSO.  An example of a partner application is Oracle?s Portal application.  To access a partner application the user logs onto the application and is redirected to the SSO server.  The SSO server request the user?s credentials, verifies them against the data stored in OID and if valid, sets an encrypted cookie and redirects the user back to the application.  On subsequent request to the application, mod_osso verifies the cookie information and either allows access to the application or redirects the user back to the SSO server if invalid.

External Applications

External applications do not implement SSO for user authentication and in fact may not even run on the application server.  If the external application uses an HTML login form, SSO can provide the login credentials for the application.  An example of an external application is a web mail program.  When the SSO user attempts to access the web mail program, SSO will retrieve the users name and password and automatically respond to the HTML authentication form, logging the user into the program.  SSO in Oracle Application Server 10g has added to this feature so that an SSO user can automatically login to a windows server using a Kerberos ticket.  SSO also allows the use of x.509 certificates for authentication.

When logging onto an external application, mod_osso captures the HTML authentication form and looks in SSO for credentials.  If you have not yet logged onto SSO you will be asked to logon.  If this is the first time you have logged onto this site, SSO will prompt you for your site credentials.  SSO will then return the HTML form data to the site for authentication.  Upon subsequent returns to the site, mod_osso will capture the authentication form and automatically return you authentication credentials for that site.  One significant difference between partner and external applications is logging off.  When you log off a partner application you log off of SSO and must log back in to continue to access them.  External programs that do not re-verify your authentication with each access (almost all of them) will not know that you logged out of SSO.  The user is required to log out of each external program to insure against unauthorized access.

Administering Single Sign-On

The first step is to assign privileges to the users that will be administering SSO.  Using the Oracle Directory Manager application discussed above to add users to the iASAdmin group in OID.  Those users in the iASAdmin group have the privileges needed to administer SSO.  Start the Oracle Directory Manager using the command below and log on as cn=orcladmin.

$INFRA_ORACLE_HOME/bin/oidadmin

Note that the user cn=orcladmin is not the same user as orcladmin.  You must log in using the userid cn=orcladmin.  Navigate thru Entry Management, OracleContext, and Groups to the iASAdmin group as shown in Figure 12 ? 11.

Figure 11: Oracle Directory Manager: iASAdmin Group

Scroll to the bottom of the Properties tab and add the administration users to the unique member textbox. Select Apply to set you changes.  If you attempt to add a user who does not currently have an account in OID, you will receive an exception error.

When a member of the iASAdmin group connects to SSO using the command below, the SSO page will contain an additional link at the top called ?SSO Server Administration?.  This link will take you to the administration page.

$Infra_ORACLE_HOME/pls/orasso

The SSO Server Administration page contains three links.  The Edit SSO Server Configuration link will allow you to set the Single Sign-On session duration in hours.  This determines how long a user can be signed on before his authentication is re-verified by SSO.  It also allows you to force the SSO server to verify that the IP of the browser is the same as the IP of the verification request.  This added step is used to stop IP spoofing.

For sensitive applications Oracle provides a Global User Inactivity Timeout that by default is not set.  If you need this feature refer to the Oracle Application Server Single Sign-On Administration Guide.

The Administer Partner Applications link allows you to add, delete or edit partner applications.  As shown in Figure 12-12, to add a partner application, select the Add Partner Application link.

Figure 12:ORASSO Administer: Create Partner Application Page

Enter the application name (this is the name used by SSO) and the home URL.  When a user accesses the application home, it is redirected to the SSO server for validation.  The Success URL is the location that the SSO server redirects users to after successfully authenticating them.  Normally the Success URL is the same as the Home URL.  The Logout URL is where SSO redirects users when they logout of SSO.  This allows the application to interact with the user on logout.  When a user logs out of SSO he is passed to each of the Logout URLs for the applications he used.

The start and end date allows you to limit access to the partner application.  The application administrator data is also available if required but is not shown in to users.

The SSO Administration page Administer External Programs allows you to add, delete and edit the validate method for external programs.  Select the Add External Program link to move to the Create External Application page.  Enter the application name and URL.  Again, mod_osso will intercept the HTML validation form, retrieve the authentication data from OID and submit it back to the application.  The username/ID and password fields are the name of the fields in the HTML source for the authentication form.  You find these values by looking at the HTML source, normally by selecting View|Page Source in your browser.  While viewing the HTML source, determine how the browser is expected to return the user credentials.  Normally these are performed by a POST or GET statement.  The Additional Fields are used to return information other than the user name and password that the application may be expecting such as a company name, etc.  Again, these requirements are found in the HTML source for the authentication form.  The Field Name is the name of the item in the HTML source and the Field Value is the value SSO returns for that field.  If you select the Show User checkbox, the additional fields will be shown to the user when he signs in to the SSO server.

Again, this has been an introduction to the capabilities of Oracle Single Sign-On application.  There are many more features like language capabilities etc.  For additional information refer to the Oracle Application Server Single Sign-On Administration Guide.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.