Single Sign-On (SSO) - Oracle

Before the introduction of Application Server SSO 10g, each component within Application Server 10g required separate password and authentication management. Besides the duplication of passwords, the lack of a unified security interface presented huge maintenance issues and also compromised the overall manageability of the application.

Without SSO, every user is required to maintain a distinct password for every application in the enterprise. As anyone who has dozens of passwords can tell you, this means that users must write down the passwords, which can cause a serious security breach. With SSO, each user has only one password for all applications within the Application Server 10g framework.

Unlike traditional Oracle applications, SSO is designed for web-based users. Any Oracle system can be web enabled, and end users can securely access their applications from the Internet, anywhere in the world. The central components of Application Server SSO 10g are the mod_osso module and the SSO login server, and these will be the focus of our SSO exploration. As an Application Server 10g administrator, you are responsible for maintaining enterprise security, and knowledge of SSO administration is required.

Application Server 10g uses two techniques for end-user authentication, one for local “partner” applications (internal) and another for external applications. Because of the infinite possible authentication mechanisms of external applications, they cannot be integrated into SSO, and LDAP entries are used to manage security.

• Local partner applications Local application authentication is performed from a lookup table within the iasdb schema on the repository. The lookup table contains all of the data, including the user ID, password, and privileges for local users.

• External applications External SSO identification allows any third-party products to be incorporated in an Application Server 10g system. External applications use the Oracle Internet Directory, and Application Server 10g handles authentication using standard LDAP entries. At connect time, Application Server 10gbinds to OID and looks up the remote user’s credentials in the appropriate directory on the server.

This chapter focuses on SSO administration, and you can find details on user assignment and application management with SSO in Chapter 12. Let’s get started by exploring the roles of the SSO administrator and SSO configuration and then look at the mod_osso utility to learn how it is used to administer Application Server 10g SSO security.

The SSO administrator is responsible for all access controls and must manage all users who will connect to an application, all applications within the system, and the assignment of users to applications. There are three basic areas of SSO administration: server configuration, user management, and application management. We will focus on the server installation and configuration of SSO.

It’s important to note that SSO should run seamlessly once it has been installed and configured. Afterward, the ongoing management of applications and users becomes trivial.

If you are using Oracle Portal or external applications, there are additional administrative interfaces to SSO. This is because Portal and any external applications must have customized authentication code. Because SSO controls the security for the entire Application Server 10g enterprise, it is critical that administrators ensure that proper security is maintained.

For more details on the daily operational use of SSO, see Chapter 12.

The configuration of SSO involves the creation and management of the server-side components for the SSO login server. These configuration tasks include

• Allocate SSO directories These must be allocated with the proper OS permissions to maintain security.

• Set up SSO configuration files These must contain the correct values for your system.

• Configure SSO programs These must be configured properly.

• Establish SSO library routines These must have proper group permissions.

These are relatively trivial tasks, but crucial to the successful use of SSO. Let’s start by looking at the SSO directory structures and understand the purpose and functions of the components within each directory.

The SSO log-in server will have the following directories allocated at install time. Each of these directories serves a specific purpose to SSO and contains important scripts and executables.

• $ORACLE_HOME/reports/conf This directory has the configuration files for Oracle Reports.

• $ORACLE_HOME/sso/bin This directory contains SSO executables.

• $ORACLE_HOME/dcm/bin This is the directory for the DCM utility files.

• $ORACLE_HOME/Apache/Apache/conf This is the location of the mod_osso configuration file.

• $ORACLE_HOME/sso/lib This contains the ossoreg.jar file and other SSO library routines.

These are the main driving directories for SSO, and they contain important programs for SSO management. One of the most important is the SSO configuration utility. It is located in $ORACLE_HOME/sso/bin/ssocfg.sh, and ssocfg.sh is a shell script that invokes Java routines to manage the SSO layer. The ssocfg.sh script accepts the new_host_name and new_port name as arguments. For example, if you wanted to add server diogenes on port 1446, you would issue the following command:

ssocfg.sh diogenes 1446

Internally, the ssocfg.sh script issues the following Java invocation, calling the oracle.security.sso.SSOServerConfig Java program:

java oracle.security.sso.SSOServerConfig $*

Turning on SSO requires adjusting the SINGLESIGNON parameter in the rwservlet configuration file (rwservlet.properties). With singlesession=yes, you are telling Application Server 10g that you will use SSO to authenticate users. As we have noted, the rwservlet configuration file is usually found in the $ORACLE_HOME/reports/conf directory.

After you have completed configuring the SSO server, you must configure OHS to use SSO. This is done by making an entry in the mod_osso.conf file and enabling mod_osso in the OMS configuration file. The file osso.conf contains a partner registration record registered with the Single Sign-On server. Once the OHS is configured for SSO, you can use SSO to protect individual resources via the SSO server. There are several important directives in the file:

• OSS idle timeout  If you set OssoIdleTimeout on, Application Server 10g will invoke a global inactivity timeout to disconnect idle sessions.

• OSS IP check  If you set OssoIpCheck on, Application Server 10g SSO will invoke an IP address check to ensure that the authenticating browser is the same as the browser requesting access to protected facilities.

The SSO login server is the component of Application Server 10g that accepts the users’ passwords and manages their access to all Application Server 10g applications. After a user enters an accepted password, Application Server 10g sends a message to all applications that this user has been authenticated and (optionally) stores a cookie on the browser. This cookie is used to avoid the need to reenter the password during subsequent visits.

TIP

Any web browser that uses SSO should be configured to accept cookies because the end user will become annoyed with the repeated login screens that are displayed without cookie support.

Because SSO governs security for the whole enterprise, you must have Full Administrator privileges on the login server to configure the SSO login server. If you want to access the SSO login server from Application Server Portal 10g, you must be an Authorized Application Server Portal 10g Administrator.

The Application Server 10g repository has some important SSO log tables that assist in tracking SSO interaction and errors. Let’s take a look at these log tables.