6 Multilevel Authentication

This document explains how to configure a single sign-on system that assigns different authentication levels to different partner applications. Such a system enables the administrator to tailor authentication behavior to the security level of the application requested.

The document contains the following topics:

What Is Multilevel Authentication?
How Multilevel Authentication Works
Components of a Multilevel System
Configuring Multilevel Authentication

6.1 What Is Multilevel Authentication?

OracleAS Single Sign-On enables you to assign different authentication levels to the applications that it protects. You can then map these authentication levels to specific authentication plugins. You may, for example, configure a highly sensitive application to require a user certificate and a less sensitive application to require a user name and password.

6.2 How Multilevel Authentication Works

Figure 6-1 illustrates how multilevel authentication works.

Figure 6-1 Multilevel Authentication Flow

Description of "Figure 6-1 Multilevel Authentication Flow"

The user has already authenticated to Application A. He or she now goes to Application B.
Application B redirects the user to the single sign-on server.
Because Application B has a higher authentication level than Application A, the single sign-on server forces the user to authenticate again, this time with a higher credential.

Note:
In release 10.1.2, authentication is at the root level of a partner application. You cannot assign authentication levels to URLs under the root.

6.3 Components of a Multilevel System

The following topics are key to understanding how multilevel authentication works:

Authentication Levels
Authentication Plugins

6.3.1 Authentication Levels

Authentication levels are parameters that enable you to specify a particular authentication behavior for an application. You use the policy.properties file to configure the authentication level names and values that make up these parameters. This file is at ORACLE_HOME/sso/conf. A copy of it appears in Appendix C.

Table 6-1 provides examples of authentication levels. You can customize these to suit your deployment requirements and can provide additional ones.

Table 6-1 Default Authentication Levels

Authentication Level Names	Authentication Level Values
LowSecurity	20
LowMediumSecurity	30
MediumSecurity	40
MediumHighSecurity	50
HighSecurity	60

The authentication level names must be unique. For example, a system that includes both NoSecurity=10 and NoSecurity=20 is unacceptable. The lower the numeric value of a level, the lower the level of security. Values must, however, be positive integers.

Users who log in at a high level such as MediumHighSecurity and then attempt to access a lower-level application are not rechallenged for credentials. Conversely, users who log in at a low-level application such as LowMediumSecurity and then attempt to access a higher-level one are challenged with the required level.

6.3.2 Authentication Plugins

An authentication plugin is an implementation of a specific authentication method. This method collects credentials from users and authenticates them.

You can pair one of the authentication levels introduced in the preceding section with one of the authentication methods described in the bulleted list that follows. The authentication level that an authentication plugin maps to is deployment specific. You use policy.properties to achieve the pairing.

Password authentication

This is the default, standard method.
Digital certificates

See Chapter 8 for a discussion of certificate authentication.
Windows native authentication

See the chapter about integrating with Microsoft Active Directory in Oracle Identity Management Integration Guide.

6.4 Configuring Multilevel Authentication

Applications not configured for a specific authentication level default to password authentication and are assigned an authentication level of MediumSecurity. If you require a different authentication level, you must modify policy.properties. Use the configuration scenario that follows for guidance.

6.4.1 Usage Scenario

This usage scenario explains how two hypothetical partner applications are configured to use different authentication levels and plugins. It assumes these conditions:

Application pa1 is deployed on host pa1.mydomain.com. It listens on port 7777.
pa1 is already registered with the single sign-on server.
pa1 must use certificate authentication.
Application pa2 is deployed on host pa2.mydomain.com. It listens on port 7777.
pa2 is already registered with the single sign-on server.
pa2 must use password authentication.

6.4.2 Configuration Steps

Modify policy.properties with the following configurations.

Choose the name of the authentication level from policy.properties. If necessary, add a new authentication level and corresponding name to the file.
Assign authentication levels to the root URLs of the two partner applications:
```
pa1.mydomain.com\:7777 = HighSecurity
pa2.mydomain.com\:7777 = MediumSecurity
```
Note:
Be sure to include the backslash after the domain name.
Assign authentication plugins to the authentication level names that you assigned in step 1:
```
HighSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOX509CertAuth
MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth
```
Note that the authentication plugin name is a combination of the authentication level name that you assigned in step 1 and the suffix _AuthPlugin.

Save policy.properties; then restart the single sign-on middle-tier.

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY

Test the partner applications.