Skip Headers
Oracle® Application Server Single Sign-On Administrator's Guide
10g (

Part Number B15988-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

8 Signing On with Digital Certificates

Single sign-on with X.509 client certificates provides a stronger degree of security than simple authentication. It offers the benefit that partner applications are, by default, PKI enabled when the single sign-on server is PKI enabled.

This chapter contains the following topics:

8.1 How Certificate-Enabled Authentication Works

Figure 8-1 depicts the authentication flow for certificate-enabled sign-on.

Figure 8-1 Certificate-Enabled Single Sign-On

Graphic of a process. A text description follows.
Description of "Figure 8-1 Certificate-Enabled Single Sign-On"

  1. The user tries to access a partner application.

  2. The partner application redirects the user to the single sign-on server for authentication. As part of this redirection, the browser sends the user's certificate to the login URL of the server (2a). If it is able to verify the certificate, the server returns the user to the requested application.

  3. The application delivers content.


    Users whose browsers are configured to prompt for a certificate-store password may only have to present this password once, depending upon how their browser is configured. If they log out and then attempt to access a partner application, the browser passes their certificate to the single sign-on server automatically. This means that they never really log out. To effectively log out, they must close the browser.

8.2 System Requirements

The following criteria must be met before certificate-enabled single sign-on can proceed:

8.3 Configuring the Single Sign-On System for Certificates

Certificate-enabled single sign-on is not a default option in OracleAS, and it must be configured after installation. Before configuring certificate authentication, you must enable the single sign-on system for SSL. Perform the tasks in Chapter 7; then return to this section and configure the following components for certificates:

8.3.1 Oracle HTTP Server

Configuring the Oracle HTTP Server for certificates consists of adding parameters to the ssl.conf file and, optionally, choosing the certificate authority that issues server and user certificates. Setting SSL Parameters

To set the required SSL parameters, complete the following steps:

  1. Go to ssl.conf. The file is at ORACLE_HOME/Apache/Apache/conf.

  2. In the SSL Virtual Host Context section of ssl.conf, add or edit the parameters listed in Table 8-1. At the same time, verify that the SSLEngine parameter has been set to on. This should have been done as part of configuring the Oracle HTTP Server for SSL.

Table 8-1 HTTP Parameters for Certificate-Enabled Single Sign-On

Parameter Description

The location, or path, of the server wallet. The default location is ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default.

Note:The actual location of the Oracle home must be substituted for the variable.

If OracleAS Certificate Authority is installed in the same Oracle home as OracleAS Single Sign-On, and you want to use this CA to issue certificates, the wallet location is ORACLE_HOME/oca/wallet/ssl. See "Choosing a Certificate Authority" for details.


Password for the server wallet


The verification type for client certificates. These are the three types:

  • none—SSL without certificates

  • optional—server certificate and optionally client certificate

  • require—server and client certificates

You must choose either optional or require. Choosing a Certificate Authority

If you have OracleAS Certificate Authority installed and want to use this CA to issue certificates, edit ssl.conf to point to the desired Oracle CA wallet. You can either use the Oracle CA wallet described in Table 8-1 or have the Oracle CA issue a wallet that is specifically for the single sign-on server. If you choose the first option, copy the wallets that are in the wallet directory for the Oracle CA to the default wallet directory. If you choose the second option, see Chapter 7 in Oracle Application Server Certificate Authority Administrator's Guide for instructions. The relevant section is "Server/SubCA Certificates Tab." This is a subsection of "End-User Tabs and Processes." Once you obtain the wallet, edit ssl.conf to point to the wallet's location.

You may, of course, elect to use a third-party CA. In this case, too, you must edit ssl.conf to point to the wallet's location as explained in Table 8-1.

Using OracleAS Single Sign-On in conjunction with OracleAS Certificate Authority simplifies the certificate provisioning process. You can configure the Oracle CA to broadcast the URL for its UI to single sign-on users. Users can then use this link to request a single sign-on certificate that is automatically linked to their entry in Oracle Internet Directory.

8.3.2 Single Sign-On Server

Configuring the single sign-on server to accept certificates consists of these tasks:

Perform at least the first and the last step. Add the middle two if you want to customize the user name mapping module. The default module for user name mapping matches the distinguished name (DN) in the client certificate with a single sign-on user in Oracle Internet Directory. The default implementation assumes that the user's DN in the directory is the same as the certificate DN. A module that maps a field in the certificate DN to the user's name in Oracle Internet Directory is also available. If you want to substitute this module for the DN mapping module, modify the CertificateMappingModule parameter as prescribed in the third task. Configure with the Default Authentication Plugin

Update the DefaultAuthLevel section of the file with the correct authentication level for certificate sign-on. This file is at ORACLE_HOME/sso/conf. Set the default authentication level to this value:

DefaultAuthLevel = MediumHighSecurity

Then, in the Authentication plugins section, pair this authentication level with the default authentication plugin:

MediumHighSecurity_AuthPlugin =

For your convenience, is available in Appendix C, "". Modify the Configuration File for the Authentication Plugin (Optional)

The file contains the parameters that follow. The file is in the same directory as


Omit this step if you are using the DN-based mapping module. CertificateMappingModule

This parameter is set to the class file that performs user name mapping. The parameter can have one of two default values:


The first module assumes that the user's DN in the directory is the same as the certificate DN. This is the default, out-of-the-box setting. The second module assumes that the first attribute in the user DN in the certificate is cn. It also assumes that this attribute is the same as the user nickname in the default realm of Oracle Internet Directory. If, for example, the user DN in the certificate is cn=john,cn=users,dc=acme,dc=com, you can use the second module. If, on the other hand, the DN is,cn=john,cn=users,dc=acme,dc=com, you cannot use the module. You can, however, write a mapping module that uses this DN. See "Customize the User Name Mapping Module (Optional)" for details. If you decide to write your own module, set CertificateMappingModule to the class file name for your implementation. CheckUserCertificate

This parameter indicates whether the user certificate must be verified in Oracle Internet Directory. The default value is true. If you deem the SSL protection provided by the Oracle HTTP Server to be sufficient, set this parameter to false. CertificateAuthFailureUrl

If certificate authentication fails, the user is redirected to this URL, which displays an error message. CertificateAuthFallback

Set this parameter to true if you want to make password authentication available to a user who tries to log in without a valid certificate. This fallback does not occur by default. You must enable it. If the parameter is set to false or is absent entirely, users see a message that tells them they must present a valid certificate. You may have to add CertificateAuthFallback to the file. Place it at the end this way:

#Allow authentication fallback


If CertificateAuthFallback is set to true, you cannot use multilevel authentication. Customize the User Name Mapping Module (Optional)

To customize the user name mapping module, implement a mapping module based on Refer to the example mapping modules shipped with this release. Again, these modules are and


Omit this step if you are not writing your own mapping module.

The example modules contain the following classes:

  • Mapping module Interface

    This interface contains the following methods:

    public IPASUserInfo getUserInfo(
           javax.servlet.http.HttpServletRequest request)
           throws IPASException;
  • User information class

    This class contains user information such as the user nickname and user DN. The package name is The constructor looks like this:

    Public IPASUserInfo(
           String userNickName
           String realmNickname)
    Public IPASUserInfo(
           String userNickName,
           String userDN,
           String userGUID,
           String realmNickname,
           String realmDN,
           String realmGUID)
  • Exception class

    A problem with user name mapping raises this exception. The class name is The super class is java.lang.Exception. The constructor looks like this:

    public IPASException()
    public IPASException(String Message)
  1. Extract ipassample.jar, the file that contains the modules:

    ORACLE_HOME/jdk/bin/jar -xvf ORACLE_HOME/sso/lib/ipassample.jar
  2. Create a Java class that implements the following interface:
  3. Compile your custom implementation:

    ORACLE_HOME/jdk/bin/javac -classpath ORACLE_HOME/sso/lib/
    ipastoolkit.jar:ORACLE_HOME/lib/servlet.jar -d class_directory
  4. Jar your class file and place it into ORACLE_HOME/sso/plugin:

    ORACLE_HOME/jdk/bin/jar -cvf ORACLE_HOME/sso/plugin/CertMapImpl.jar class_directory

    This step assumes that you do not have individual class files in the plugin directory. If the directory contains the individual files, they may be duplicated.

  5. Update with your implementation. See "Modify the Configuration File for the Authentication Plugin (Optional)". Restart the Single Sign-On Middle Tier

After configuring the server, restart the middle tier:

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

8.3.3 Oracle Internet Directory

For certificate-based authentication to be successful, the user certificate must be present in Oracle Internet Directory. If the certificate is issued by OracleAS Certificate Authority, the certificate is published in the directory automatically. This may also be true if the CA is in-house. If the certificate issuer is a third-party CA, a self-service application can fulfill this function. Or the directory administrator can try to add the certificate to the directory as an LDIF file, using the command-line tool ldapmodify.


If you use ldapmodify to publish the certificate, set the appropriate globalization support variable for your environment before running the tool. Here is an example:

  • UNIX:

  • Windows:


In UNIX, you may have to use a different procedure to set this variable if you are using a shell other than csh or tcsh.

Here is the syntax of ldapmodify:

-h directory_host
-p directory_ssl_port
-D "directory_administrator"
-w administrator_password
-f file_name.ldif

In the example LDIF file that follows, the certificate of user jsmith is represented as an attribute of his entry in the directory. The attribute type is usercertificate. The attribute value is the long string that follows the attribute type.

dn: cn=jsmith,cn=users,dc=realm1,dc=oracle,dc=com
changetype: modify
replace: usercertificate

Because it is a non-ASCII value, the certificate must be encoded in base 64 format, as shown here. Unlike other attributes, a base 64 attribute requires a double colon (::) as a delimiter. Note, too, that the use of a tab enables a base 64 attribute to be folded.

8.4 Maintaining a Certificate Revocation List

To ensure that users are unable to log in using invalid or expired certificates, the administrator must maintain an up-to-date certificate revocation list (CRL) on the Oracle HTTP Server. The CA that issued the certificate must provide this list. The ca-bundle.crl file can be used to maintain it. The path to the CRL file must be ORACLE_HOME/Apache/Apache/conf.

OracleAS users who use digital certificates to authenticate must not be able to update the userCertificate attribute in their directory entry. The reason is the potentially long lapse time between the revocation of a certificate and the update of the CRL. Once invalid users pass a CRL check, the only bar to login is the userCertificate setting. Fortunately, Oracle Internet Directory, by default, denies users access to userCertificate. The attribute must be modified only by trusted entities such as the single sign-on administrator, OracleAS Certificate Authority, or a third-party certificate authority.

For details about implementing and maintaining a CRL, see comments in the SSL Virtual Host Context section of ssl.conf.