Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) B14078-02 |
|
Previous |
Next |
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:
Figure 8-1 depicts the authentication flow for certificate-enabled sign-on.
Figure 8-1 Certificate-Enabled Single Sign-On
The user tries to access a partner application.
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.
The application delivers content.
Note: 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. |
The following criteria must be met before certificate-enabled single sign-on can proceed:
The single sign-on server and Oracle Internet Directory must be installed.
The Oracle HTTP Server must have a valid server certificate installed.
The client certificate DN must be chosen in such a way that it meets one of the following two criteria:
The DN of the user certificate is the same as the user DN in Oracle Internet Directory
The DN of the user certificate contains the user nickname and, optionally, the name of the realm that the user belongs to
The certificate of the client certificate issuer must be installed as a trusted certificate on the single sign-on server.
The certificate of the server certificate issuer must be installed as a trusted certificate in the user's browser.
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:
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.
To set the required SSL parameters, complete the following steps:
Go to ssl.conf
. The file is at ORACLE_HOME
/Apache/Apache/conf
.
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 |
---|---|
SSLWallet |
The location, or path, of the server wallet. The default location is 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 |
SSLWalletPassword |
Password for the server wallet |
SSLVerifyClient |
The verification type for client certificates. These are the three types:
You must choose either |
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.
Configuring the single sign-on server to accept certificates consists of these tasks:
Configure policy.properties with the Default Authentication Plugin
Modify the Configuration File for the Authentication Plugin (Optional)
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.
Update the DefaultAuthLevel
section of the policy.properties
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 = oracle.security.sso.server.auth.SSOX509CertAuth
For your convenience, policy.properties
is available in Appendix C, "policy.properties".
The X509CertAuth.properties
file contains the parameters that follow. The file is in the same directory as policy.properties
.
Note: Omit this step if you are using the DN-based mapping module. |
This parameter is set to the class file that performs user name mapping. The parameter can have one of two default values:
oracle.security.sso.server.auth.SSOCertMapperDn
or
oracle.security.sso.server.auth.SSOCertMapperNickname
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 e=john.smith@acme.com,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.
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
.
If certificate authentication fails, the user is redirected to this URL, which displays an error message.
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 CertificateAuthFallback=true
Note: IfCertificateAuthFallback is set to true , you cannot use multilevel authentication.
|
To customize the user name mapping module, implement a mapping module based on oracle.security.sso.ias904.toolkit.IPASUserMappingInterface
. Refer to the example mapping modules shipped with this release. Again, these modules are SSOCertMapperDN.java
and SSOCertMapperNickname.java
.
Note: 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 oracle.security.sso.ias904.toolkit.IPASUserInfo
. 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 oracle.security.sso.ias904.toolkit.IPASException
. The super class is java.lang.Exception
. The constructor looks like this:
public IPASException() public IPASException(String Message)
Extract ipassample.jar
, the file that contains the modules:
ORACLE_HOME/jdk/bin/jar -xvf ORACLE_HOME/sso/lib/ipassample.jar
Create a Java class that implements the following interface:
oracle.security.sso.ias904.toolkit.IPASUserMappingInterface
Compile your custom implementation:
ORACLE_HOME/jdk/bin/javac -classpath ORACLE_HOME/sso/lib/ ipastoolkit.jar:ORACLE_HOME/lib/servlet.jar -d class_directory java_file_name
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.
Update x509CertAuth.properties
with your implementation. See "Modify the Configuration File for the Authentication Plugin (Optional)".
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
.
Note:
|
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:
setenv NLS_LANG AMERICAN_AMERICA.UTF8
Windows:
set NLS_LANG=AMERICAN_AMERICA.UTF8
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
:
ORACLE_HOME/bin/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 usercertificate::MIIC3TCCAkYCAgP3MA0GCSqGSIb3DQEBBAUAMIG8MQswCQ NYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEXMBUGA1UEBxMOUmVkd29vZCBTaG9yZXMxGzAZBg VBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWV2ViIFNpbmdsZSBTaWduLU9uLCBTVDEeMBwA 1UEAxMVQ2VydGlmaWNhYoEHmF4gomtc4mxSKh/zAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAKwXoCLDRqm KY9LQtIjLnCaIJKUZmS1Qj+bhu/IHeZLGHg4TJg3O2XVA5u/VxwjLeGBqLXy2z7o3RujNKx2CVx6p/0Hk jnw4w6KVau2hcBgC9m4kzUGhHJ9b65v/zx7dIUKyJr4RF+lJhJg4/oYXxLrYHp5NAkHP4htT0gqCXiI=
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.
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
.