|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) Part No. B14078-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) Part No. B14078-01 |
|
|
Previous |
Next |
This chapter explores nondefault ways to use OracleAS Single Sign-On. It presents scenarios that you may encounter in a production environment. Some of these scenarios involve deploying and configuring the component to interact with other OracleAS components.
The chapter contains the following topics:
This section explains how to enable the single sign-on server for Secure Sockets Layer (SSL). In SSL, a secret session key is created, enabling the exchange of information over a secure channel. When the user logs in, the Web server sends the browser a digital certificate. The browser uses a public key sent by the Web server to encrypt a random number. This encrypted data is used in turn to create the secret key. Enabling the single sign-on server for SSL confers this form of protection on the server's partner applications. The process provides OracleAS with a high degree of security.
Out of the box, the single sign-on server uses the HTTP port of the Oracle HTTP Server. You can, however, configure SSL after installation. Complete the following tasks in the order listed:
|
Note: If the Oracle HTTP Server is configured for SSL (topic 1) you must configure the single sign-on server for SSL as well (remaining topics); otherwise users will be unable to access single sign-on URLs. To skirt this restriction, disable SSL directives for URLs that you want to access over HTTP. You do this by editingORACLE_HOME/sso/conf/sso_apache.conf.
|
The following steps involve configuring the Oracle HTTP Server. Perform them on the single sign-on middle tier. In doing so, keep the following in mind:
You must configure SSL on the computer where the single sign-on middle tier is running.
You are configuring one-way SSL.
You may enable SSL for simple network encryption; PKI authentication is not required. Note though that you must use a valid wallet and server certificate. The default wallet location is ORACLE_HOME/Apache/Apache/conf/ssl.wlt/default. If you want to use a different wallet, see the guidelines in the section "Oracle HTTP Server" in Chapter 7. The chapter about managing wallets and certificates in Oracle Application Server Administrator's Guide is also helpful.
To quickly enable SSL on the Oracle HTTP Server, do the following:
Back up the opmn.xml file, found at ORACLE_HOME/opmn/conf.
In opmn.xml, change the value for the start-mode parameter to ssl-enabled. This parameter appears in boldface in the xml tag immediately following.
<ias-component id="HTTP_Server">
<process-type id="HTTP_Server" module-id="OHS">
<module-data>
<category id="start-parameters">
<data id="start-mode" value="ssl-enabled"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>
Update the distributed cluster management database with the change:
ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct opmn
Reload the modified opmn configuration file:
ORACLE_HOME/opmn/bin/opmnctl reload
Keep a non-SSL port active. The External Applications portlet communicates with the single sign-on server over a non-SSL port. The HTTP port is enabled by default. If you have not disabled the port, this step requires no action.
Apply the rule mod_rewrite to SSL configuration. This step involves modifying the ssl.conf file on the middle-tier computer. The file is at ORACLE_HOME/Apache/Apache/conf. Back up the file before editing it.
Because the Oracle HTTP Server has to be available over both HTTP and HTTPS, the SSL host must be configured as a virtual host. Add the lines that follow to the SSL Virtual Hosts section of ssl.conf if they are not already there. These lines ensure that the single sign-on login module in OC4J_SECURITY is invoked when a user logs in to the SSL host.
<VirtualHost ssl_host:port> . . . RewriteEngine on RewriteOptions inherit </VirtualHost>
Save and close the file.
Update the distributed cluster management database with the changes:
ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct ohs
Restart the Oracle HTTP Server:
ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl startproc process-type=HTTP_Server
Verify that you have enabled the single sign-on middle tier for SSL by trying to access the OracleAS welcome page, using the format https://host:ssl_port.
|
Note: If your installation has two or more middle tiers, make sure that you complete step 2 in "Configure the Oracle HTTP servers on the single sign-on middle tiers". This is a subsection of "Multiple Single Sign-On Middle Tiers, One Oracle Internet Directory," one of the deployment scenarios presented later in the chapter. |
Change all references of http in single sign-on URLs to https within the identity management infrastructure database. When you change single sign-on URLs in the database, you must also change these URLs in the targets.xml file on the single sign-on middle tier. targets.xml is the configuration file for the various "targets" that Oracle Enterprise Manager monitors. One of these targets is OracleAS Single Sign-On.
Run the ssocfg script, taking care to enter the command on the computer where the single sign-on middle tier is located. Use the following syntax:
UNIX:
$ORACLE_HOME/sso/bin/ssocfg.sh protocol host ssl_port
Windows:
%ORACLE_HOME%\sso\bin\ssocfg.bat protocol host ssl_port
In this case, protocol is https. (To change back to HTTP, use http.) The parameter host is the host name, or server name, of the Oracle HTTP listener for the single sign-on server.
Here is an example:
ssocfg.sh https login.acme.com 4443
To determine the correct port number, examine the ssl.conf file. Port 4443 is the port number that the OracleAS installer assigns during installation.
If you run ssocfg successfully, the script returns a status 0. To confirm that you were successful, restart the OC4J_SECURITY instance:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
Then try logging in to the single sign-on server at its SSL address:
https://host:ssl_port/pls/orasso/
After running ssocfg, update the targets.xml file on the single sign-on middle tier.
To update targets.xml:
Back up the file:
cp ORACLE_HOME/sysman/emd/targets.xml ORACLE_HOME/sysman/emd/targets.xml.backup
Open the file and find the target type oracle_sso_server. Within this target type, locate and edit the three attributes that you passed to ssocfg:
HTTPMachine—the server host name
HTTPPort—the server port number
HTTPProtocol—the server protocol
If, for example, you run ssocfg like this:
ORACLE_HOME/sso/bin/ssocfg.sh http sso.mydomain.com:4443
Update the three attributes this way:
<Property NAME="HTTPMachine" VALUE="sso.mydomain.com"/> <Property NAME="HTTPPort" VALUE="4443"/> <Property NAME="HTTPProtocol" VALUE="HTTPS"/>
Save and close the file.
Reload the OracleAS console:
ORACLE_HOME/bin/emctl reload
When the single sign-on server is enabled for SSL, you must specify that HTTP access be limited to those hosts that must access the server using this protocol. This is especially true in the case of those computers hosting the OracleAS installer and OracleAS Portal. In ORACLE_HOME/sso/conf/sso_apache.conf, locate and uncomment the three directives that follow; then provide a value for the Allow from parameter.
Invoke the first directive if you are installing a release 9.0.2 middle tier with a release 10.1.2 single sign-on server. This directive enables the installer to access the single sign-on server over HTTP. Replace <your_domain_name> with the fully qualified host name of the middle tier on which the installer is located; then uncomment the line. If you plan to install from more than one location, enter just a domain name.
<Location "/pls/orasso/*[Ss][Ss][Oo][Pp][Ii][Nn][Gg]"> Order deny,allow Deny from all # Allow from <your_domain_name> </Location>
OracleAS Portal must use HTTP to access the URL that provides a list of external applications. The directive that follows enables such access. Replace <your_domain_name> with the fully qualified Portal host name; then uncomment the directive. If you have more than one Portal database, enter just the domain name for these databases.
#<Location "/pls/orasso/*[Aa][Pp][Pp][Ss]_[Ll][Ii][Ss][Tt]"> # Order deny,allow # Deny from all # Allow from <your_domain_name> #</Location>
Versions of OracleAS Portal that predate release 9.0.2 use HTTP to verify whether a user exists in the single sign-on database. This last directive enables verification. Again, replace <your_domain_name> with the fully qualified Portal host name; then uncomment the directive. If you have more than one Portal database, enter just the domain name for these databases.
#<Location "/pls/orasso/[Oo][Rr][Aa][Ss][Ss][Oo].wwsso_app_admin.validate_user*">
# Order deny,allow
# Deny from all
# Allow from <your_domain_name>
#</Location>
After editing sso_apache.conf, update the repository for Distributed Cluster Management:
ORACLE_HOME/dcm/bin/dcmctl updateConfig -v -d
Issue these two commands:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
Once you have enabled the single sign-on server for SSL, reregister mod_osso on the single sign-on middle tier and on the application middle tiers. This step configures mod_osso to use the effective single sign-on URL. See "Registering mod_osso" in Chapter 4 for instructions. To reregister OracleAS Portal, an application integrated with the single sign-on SDK, use the ptlconfig tool. To learn how to use ptlconfig, see Appendix B in Oracle Application Server Portal Configuration Guide.
This section describes different ways that the single sign-on server may be deployed to improve availability. The section contains the following topics:
One Single Sign-On Middle Tier, One Oracle Internet Directory
Multiple Single Sign-On Middle Tiers, One Oracle Internet Directory
Multiple, Geographically Distributed Single Sign-On Instances
Other High Availability Deployments
|
Note: The IP addresses and host names presented in the scenarios that follow are examples only. These addresses and names may not work in an actual implementation. Substitute values that apply to your installation. |
The simplest and quickest way to deploy OracleAS Single Sign-On is to install OracleAS infrastructure components on the same computer. To do this, you choose the installation type "OracleAS Infrastructure" and the installation option "Identity Management and OracleAS Metadata Repository." When presented with the component list for this installation type, accept the default selected components.
Alternatively, you can install the single sign-on middle tier on a separate computer, choosing in succession "OracleAS Infrastructure," "Identity Management," and finally "Single Sign-On." This is the simplest distributed configuration.
Figure 8-1 shows the first type of installation. Figure 8-2 shows the second. The first is typical of a testing, staging, or development environment. The second is appropriate when you want to position a firewall between the single sign-on computer and the Oracle Internet Directory computer. Placing these servers on separate computers has the added benefit that it improves performance. In Figure 8-2, the single sign-on server might be situated within a DMZ, where it filters internet traffic. In this configuration, the directory and the database are available only to intranet users.
Figure 8-1 Default Single Sign-On Installation: One Computer
The simplest high availability scenario involves failover within the single sign-on instance itself, at the middle tier. Adding multiple middle tiers increases throughput and makes the single sign-on server more available.
In this configuration, a single HTTP load balancer is placed in front of two or more Oracle HTTP servers. At the backend is one directory server and one identity management infrastructure database. The purpose of the load balancer is to publish a single address to single sign-on partner applications while providing a farm of single sign-on middle tiers that actually service the application requests. The HTTP load balancer can detect when one of these Oracle HTTP Server instances has failed and can then fail over requests to another instance.
The usage scenario presented here assumes the following hypothetical configurations:
The directory server and identity management infrastructure database are located at oid.mydomain.com.
There are two single sign-on middle tiers. One is installed on host sso1.mydomain.com, IP address 138.1.34.172. The other is installed on sso2.mydomain.com, IP address 138.1.34.173. Both servers listen on non-SSL port 7777. Both are configured to use the directory and identity management infrastructure database located at oid.mydomain.com.
The effective URL of the single sign-on server that is published to partner applications is sso.mydomain.com, IP address 138.1.34.234. The HTTP load balancer is configured to listen on sso.mydomain.com, port 80. It load balances user requests between sso1.mydomain.com and sso2.mydomain.com.
|
Note:
|
Figure 8-3 shows two single sign-on middle tiers configured to use a single instance of Oracle Internet Directory.
Figure 8-3 Two Single Sign-On Middle Tiers, One Oracle Internet Directory
Setting up the single sign-on system presented in Figure 9–3 involves the following tasks:
Install the identity management infrastructure database, the directory server, and the single sign-on servers
Choose a single sign-on server name that will be published to partner applications. This will also be the address of the load balancer. In the scenario presented here, the address is sso.mydomain.com.
Install the OracleAS infrastructure on oid.mydomain.com, choosing the option "Identity Management and OracleAS Metadata Repository." When presented with the component list for this installation type, choose Oracle Internet Directory only.
Install the OracleAS infrastructure on the middle tiers sso1.mydomain.com and sso2.mydomain.com, choosing the option "Identity Management." When presented with the component list for this installation type, choose OracleAS Single Sign-On. Because many tasks in OracleAS involve Oracle Delegated Administration Services, you may want to choose this component too. The configuration steps that follow apply to both components.
When the Oracle Universal Installer asks you to name the directory server associated with the two single sign-on instances, enter oid.mydomain.com.
|
Note: The OracleAS installer, by default, assigns port numbers from a range of numbers. If you want the installer to assign a different port number to a component, see the section about static port numbers in the requirements chapter of Oracle Application Server Installation Guide. |
Configure the Oracle HTTP servers on the single sign-on middle tiers
When a load balancer is placed between the user and the Oracle HTTP Server, the effective URL of the single sign-on server changes. The Oracle HTTP configuration file httpd.conf on both single sign-on middle tiers must be modified to reflect this change. This file is found at ORACLE_HOME/Apache/Apache/conf.
Edit the following lines in httpd.conf on sso1.mydomain.com and sso2mydomain.com:
KeepAlive off ServerName sso.mydomain.com Port 80
|
Note:
|
This step configures the Oracle HTTP servers at the single sign-on middle tiers to listen at the effective URL, which, in the scenario presented, is sso.mydomain.com.
If you configure SSL between the browser and the load balancer, and the SSL connection terminates at the load balancer, configure mod_certheaders on both sso1.mydomain.com and sso2.mydomain.com. This module enables the Oracle HTTP Server to treat requests that it receives over HTTP as SSL requests. Add the lines that follow to httpd.conf. You can place them at the end of the file. Where they appear is unimportant.
Enter this line to load the module:
UNIX:
LoadModule certheaders_module libexec/mod_certheaders.so
Windows:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
If you are using OracleAS Web Cache as a load balancer, enter this line:
AddCertHeader HTTPS
If you are using a hardware load balancer, enter this line:
SimulateHttps on
Synchronize system clocks between the two middle tiers. The time difference between them should be no more than 10 seconds.
Run the following command to update the Distributed Cluster Management schema with the changes:
ORACLE_HOME/dcm/bin/dcmctl updateConfig -v -d
Configure the HTTP load balancer
The HTTP load balancer used can be either hardware or software. If you elect to use a software load balancer, you can use OracleAS Web Cache.
Hardware Load Balancer
If you are using a hardware load balancer, configure one pool of real servers with the addresses 138.1.34.172 and 138.1.34.173. Configure one virtual server with the address 138.1.34.234. This virtual server is the external interface of the load balancer. For instructions, consult the documentation provided by your load balancer vendor.
Software Load Balancer
If you are using OracleAS Web Cache to load balance connection requests, see the following links:
"Leveraging Oracle Identity Management Infrastructure" in Oracle Application Server Web Cache Administrator's Guide.
"Routing Single Sign-On Server Requests," also in Oracle Application Server Web Cache Administrator's Guide.
|
Note: For optimal performance, use a hardware load balancer. |
Configure the identity management infrastructure database
Run the ssocfg script on one of the single sign-on middle tiers. This script configures the single sign-on server to accept authentication requests from the externally published address of the single sign-on server. Using the example provided, the script would be run in the following way:
UNIX:
$ORACLE_HOME/sso/bin/ssocfg.sh http sso.mydomain.com 80
Windows:
%ORACLE_HOME%\sso\bin\ssocfg.bat http sso.mydomain.com 80
Note that the command example provides the listener protocol, host name, and port number of the load balancer as arguments. Recall that the load balancer address is the externally published address of the single sign-on server. If the load balancer is configured to use SSL, replace non-SSL port 80 with SSL port 443 and http with https.
Reregister mod_osso on the single sign-on middle tiers
On sso1.mydomain.com, reregister mod_osso as the partner application sso.mydomain.com; then copy the registration record to sso2mydomain.com.
To reregister mod_osso on sso1.mydomain.com:
Set the environment variable ORACLE_HOME to point to the Oracle home for sso1.mydomain.com. To learn how to do this on different platforms see "Command Example" in Chapter 4.
Run the registration script. For the URLs, be sure to substitute values appropriate for your installation. Following the example, the script creates a partner application called sso.mydomain.com.
UNIX:
$ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path orcl_home_path -site_name load_balancer_name -config_mod_osso TRUE _mod_osso_url http://load_balancer_host:load_balancer_port
%ORACLE_HOME%\sso\bin\ssoreg.bat -oracle_home_path orcl_home_path -site_name load_balancer_name -config_mod_osso TRUE _mod_osso_url http://load_balancer_host:load_balancer_port
Update the configuration for the Oracle HTTP Server in the distributed cluster management repository:
ORACLE_HOME/dcm/bin/dcmctl updateconfig
Restart the middle tier at sso1.mydomain.com:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
To update mod_osso on sso2.mydomain.com:
On the computer sso2.mydomain.com, log in to the single sign-on administration pages as the single sign-on administrator. Be sure to log in to the externally published address of the single sign-on server:
http://sso.mydomain.com/pls/orasso
Use the Administer Partner Applications page to delete the existing entry for the partner application sso2.mydomain.com.
Copy the osso.conf file from the computer sso1.mydomain.com. Make sure that you use binary mode if you FTP the file. Copy the file to ORACLE_HOME/Apache/Apache/conf/osso.
Synchronize the Distributed Cluster Management repository with the file copy. You do this by running this command on sso2.mydomain.com:
ORACLE_HOME/Apache/Apache/bin/ssotransfer ORACLE_HOME/Apache/Apache/conf/ osso/osso.conf
|
Note: Thessotransfer command should not be used to synchronize the Distributed Cluster Management repository with the mod_osso configuration file created for a virtual host. To learn how to register mod_osso for a virtual host, see "Configuring mod_osso with Virtual Hosts" in Chapter 4.
|
Update the configuration for the Oracle HTTP Server in the distributed cluster management repository:
ORACLE_HOME/dcm/bin/dcmctl updateConfig
Restart the middle tier at sso2.mydomain.com:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
If Oracle Delegated Administration Services is installed, change its base URL, using Oracle Directory Manager:
Start the tool:
UNIX:
$ORACLE_HOME/bin/oidadmin
Windows:
Click the following in succession: Start, Programs, OracleAS 10g Infrastructure, Integrated Management Tools, Oracle Directory Manager
Log in to Oracle Directory Manager as cn=orcladmin.
Go to the entry that contains the orcldasurlbase attribute:
cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext,Entry Management
Change the attribute to the following value:
http://sso.mydomain.com/
Make sure that you include the backslash after the host name.
|
Note: This step assumes that you are using the default HTTP port80. If you are not using the default, include the port number: http://sso.mydomain.com:port.
|
Test the partner application oiddas:
http://sso.mydomain.com/oiddas
Test the single sign-on administration application:
http://sso.mydomain.com/pls/orasso
In local area networks that experience high traffic, it may be beneficial to supplement multiple single sign-on middle tiers with replicated instances of Oracle Internet Directory. This arrangement provides failover not only at the middle tier, but also at the directory server. It is useful for managing rolling upgrades because replica nodes can be removed for maintenance while other nodes continue to serve users.
To learn how to deploy an Oracle Identity Management system that uses multimaster replication, see the appendix about this topic in Oracle Identity Management Concepts and Deployment Planning Guide. The appendix provides detailed steps for configuring every component in the identity management infrastructure.
Server availability is critical for an enterprise whose operations are widely distributed geographically. If the enterprise uses a single server to authenticate remote users over a wide area network, the authentication time can be lengthy. To shorten network round-trips and speed access to applications, the enterprise can implement multiple, geographically distributed instances of the single sign-on server. This arrangement enables users to travel to remote locations and be authenticated by the nearest server, regardless of where applications are located.
In this scenario, single sign-on database tables are replicated over either a local area network or a wide area network. The DNS server located at each single sign-on middle tier site must be configured to resolve the effective address of the single sign-on server to the single sign-on instance that is nearest to the user.
The usage scenario presented here assumes the following hypothetical configurations:
There are two single sign-on middle tiers: londonsso.mydomain.com and tokyosso.mydomain.com. The effective address of the single sign-on server is sso.mydomain.com.
There are two directory servers/identity management infrastructure databases associated with the two single sign-on middle tiers: londonoid.mydomain.com and tokyooid.mydomain.com.
For replication purposes, londonoid.mydomain.com is the master definition site (MDS), the site from which the replication scripts are run and data is first replicated. tokyooid.mydomain.com is the remote master site (RMS), the site to which data is replicated.
The single sign-on middle tiers and the identity management infrastructure databases are located on separate computers.
Figure 8-4 depicts what this geographically distributed system looks like once it is deployed.
Figure 8-4 A Highly Available, Geographically Distributed Single Sign-On System
The geographically dispersed single sign-on system shown in Figure 8-5 incorporates steps presented in "Multiple Single Sign-On Middle Tiers, One Oracle Internet Directory" and "Configuring the Identity Management Database for Replication".
Install Oracle Internet Directory on the MDS, londonoid.mydomain.com, and on the RMS, tokyooid.mydomain; then set these servers up as a replication group. For instructions, see Oracle Internet Directory Administrator's Guide. These procedures cover both installation and replication. For replication concepts, see also Oracle Internet Directory Administrator's Guide.
Install the OracleAS infrastructure on the middle tier londonsso.mydomain.com, choosing the option "Identity Management." When presented with the component list for this installation type, choose "Single Sign-On." When the Oracle Universal Installer asks you to name the directory server associated with this single sign-on instance, enter londonoid.mydomain.com.
Repeat step 2, this time on middle tier tokyosso.mydomain.com. In this case, you must associate the single sign-on server with the directory server located at tokyooid.mydomain.com.
Synchronize single sign-on schema passwords between the MDS database and the RMS database. To do this, complete step 2 in "Configuring the Identity Management Database for Replication".
Although two single sign-on instances are now running at different locations, only one effective server URL is published to partner applications. Configure the single sign-on server to use this URL. In this scenario, we call the URL sso.mydomain.com. See "Configure the Oracle HTTP servers on the single sign-on middle tiers" for instructions.
Add a DNS alias, sso.mydomain.com, that points to the single sign-on middle tiers. Configure the DNS server to rout the user to the nearest middle tier when single sign-on authentication is required. When, for example, a London user is redirected to http://sso.mydomain.com, the DNS server should route the user to http://londonsso.mydomain.com. Similarly, a Tokyo user redirected to http://sso.mydomain.com should be routed to http://tokyosso.mydomain.com.
Note that some advanced DNS server products may be able to route users to the nearest server based on the geographic location.
OracleAS supports cold failover clusters, disaster recovery, and backup and recovery for single sign-on as well as for other OracleAS components.
A cold failover cluster is a group of loosely coupled computers that together provide a single view of network services. Cluster software enables the logical IP address and processes of the primary node to be moved to a secondary node in the event that the primary fails. The node running the infrastructure is "hot." The node waiting to take over is "cold." Hence the term cold failover.To learn more about cold failover clusters, see the chapter about infrastructure high availability in Oracle Application Server High Availability Guide.
A disaster recovery deployment consists of two identically configured sites—one primary (production), the other secondary (standby). Both sites may be dispersed geographically and connected by a wide area network. When the primary site becomes unavailable due to a disaster, the secondary site can become operational within a reasonable amount of time. Client requests are always routed to the site playing the production role. After failover occurs, client requests are routed to the secondary site, which then assumes the production role. Both sites have identical middle tier servers, and these servers are also identical between the two sites. To learn more about disaster recovery, see the chapter devoted to this topic in Oracle Application Server High Availability Guide.
Backup and recovery are terms used to describe strategies and procedures for preventing data loss and reconstructing lost data. To learn more about backup and recovery, see the chapter devoted to this topic in Oracle Application Server Administrator's Guide.
This section describes how to replicate the identity management database between two or more instances. Note that OracleAS Single Sign-On and Oracle Internet Directory share the scripts and procedures that replicate database tables. Before continuing with this section, become familiar with the following material:
"Directory Replication Concepts" in Oracle Internet Directory Administrator's Guide
"Oracle Directory Replication Administration" in Oracle Internet Directory Administrator's Guide
"Replication-Management Command-Line Tools Syntax" also in Oracle Internet Directory Administrator's Guide
The section covers the following topics:
The identity management infrastructure uses Oracle9i Advanced Replication to replicate tables between two databases. This feature propagates data changes between databases asynchronously. In other words, suppliers write changes to single sign-on tables and periodically send batched changes to consumers, servers that replicate this data. All of the servers in a multiple, geographically distributed system can either propagate or receive data. This arrangement is called multimaster replication. Figure 8-5 illustrates the process.
The single sign-on administrator uses the single sign-on administration application to modify single sign-on partner applications or configuration data. This process modifies the corresponding table entry in the identity management infrastructure database.
Oracle9i Advanced Replication copies the change to a deferred transaction queue.
At a scheduled interval, Oracle9i Advanced Replication pushes transactions in the deferred transaction queue to the single sign-on table on the consumer side.
Before proceeding with this section, become familiar with multimaster replication concepts in Oracle Internet Directory Administrator's Guide.
You may also want to familiarize yourself with the deployment scenario presented in "Multiple, Geographically Distributed Single Sign-On Instances". This section describes the circumstances under which single sign-on replication occurs.
The sequence for enabling the identity management database for replication is as follows:
Follow the instructions in Oracle Internet Directory Administrator's Guide to install and configure a multimaster replication group. Note that single sign-on tables are replicated as part of this process.
After running the replication scripts, the administrator must run scripts to synchronize schema passwords among replicated nodes and to establish a connection between the single sign-on server and the directory.
On the MDS, run the ssoReplSetup.jar tool to synchronize single sign-on schema passwords between the MDS database and the RMS database. This step must be repeated for each RMS. Table 8-1 defines the tool parameters.
To run the script:
Go to ORACLE_HOME/sso/lib.
Set the library path:
UNIX (csh and tcsh):
setenv LD_LIBRARY_PATH $ORACLE_HOME/lib32:$LD_LIBRARY_PATH
Windows:
set PATH=%ORACLE_HOME%\bin:%PATH%
Issue this command:
ORACLE_HOME/jdk/bin/java -jar ssoReplSetup.jar [-prompt] mds_oid_host mds_oid_port mds_oid_admin mds_oid_password mds_ssl_enabled rms_oid_host rms_oid_port rms_oid_admin rms_oid_password rms_ssl_enabled rms_db_sys_password [-help]
Table 8-1 Parameters for ssoReplSetup
| Parameter | Description |
|---|---|
mds_oid_host
|
Host name of the MDS directory server. |
mds_oid_port
|
Port number of the MDS directory server. |
mds_oid_admin
|
Bind DN—that is, the user authenticating to the MDS directory server. |
mds_oid_password
|
Bind password of the MDS directory server. |
mds_ssl_enabled
|
Indicates whether the MDS has SSL enabled. Can be either Y or N. Note that this parameter is case insensitive.
This parameter is usually set to |
rms_oid_host
|
Host name of the RMS directory server. |
rms_oid_port
|
Port number of the RMS directory server. |
rms_oid_admin
|
Bind DN—that is, the user authenticating to the RMS directory server. |
rms_oid_password
|
Bind password of the RMS directory server. |
rms_ssl_enabled |
Indicates whether the RMS has SSL enabled. Can be either Y or N. Note that this parameter is case insensitive.
This parameter is usually set to |
rms_db_sys_password
|
SYS password of the RMS database. |
-prompt |
Prompts you for all values from the console. |
-help |
Displays usage notes. |
|
Note: Repeat step 2 for each additional RMS node. |
If you want to add a node to an existing single sign-on replication group and have not replicated Oracle Internet Directory to this node, follow the instructions in Oracle Internet Directory Administrator's Guide. To configure this new node for single sign-on, install the single sign-on middle tier and repeat step 2 in "Configuring the Identity Management Database for Replication".
To delete a node from the single sign-on replication group, follow the instructions in Oracle Internet Directory Administrator's Guide.
OracleAS Single Sign-On can have reverse proxies deployed in front of it. Proxies fulfill various functions:
They terminate an SSL connection at the proxy instead of at the single sign-on server.
They limit the number of ports exposed on a firewall
Whatever proxy you use in front of the single sign-on server, the configurations that follow apply. They assume that you have already installed OracleAS Single Sign-On and the proxy server. To install the proxy, use instructions provided by your proxy vendor.
In network configurations where a range of distinct proxy addresses "front" the single sign-on server, the single sign-on IP check feature must be turned off. IP check is turned off by default, but to verify this, go to the Edit SSO Server page. To learn how to access this page, see "Accessing the Administration Pages" in Chapter 2. Once into the Edit SSO Server page, make sure that the box Verify IP addresses for requests made to the SSO Server is deselected.
To enable a proxy server, do the following:
Run the ssocfg script on the single sign-on middle tier. This script changes the host name stored in the single sign-on server to the proxy host name. Use the following command syntax, entering values for the protocol, host name, and port of the proxy server:
UNIX:
$ORACLE_HOME/sso/bin/ssocfg.sh http proxy_server_name proxy_port
Windows:
%ORACLE_HOME%\sso\bin\ssocfg.bat http proxy_server_name proxy_port
If the server is configured for SSL, substitute https for http and an SSL port for a non-SSL port.
After running ssocfg, update the targets.xml file on the single sign-on middle tier. See "Update targets.xml" for instructions.
Add the lines that follow to the httpd.conf file on the single sign-on middle tier. The file is at ORACLE_HOME/Apache/Apache/conf.
These lines change the directive ServerName from the name of the actual server to the name of the proxy:
KeepAlive off ServerName proxy_host_name Port proxy_port
Note that if you are using SSL, the port must be an SSL port such as 4443.
Enter the following lines to ensure that the single sign-on login module in OC4J_SECURITY is invoked when a user logs in to the proxy:
<VirtualHost proxy_host_name:proxy_port> . . . RewriteEngine On RewriteOptions inherit </VirtualHost>
(SSL only) If you have configured SSL communication between just the browser and the proxy server, configure mod_certheaders on the middle tier. This module enables the Oracle HTTP Server to treat HTTP proxy requests that it receives as SSL requests. Add the lines that follow to httpd.conf. You can place them at the end of the file. Where they appear is unimportant.
Enter this line to load the module:
UNIX:
LoadModule certheaders_module libexec/mod_certheaders.so
Windows:
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
If you are using OracleAS Web Cache as a proxy, enter this line:
AddCertHeader HTTPS
If you are using a proxy other than OracleAS Web Cache, enter this line:
SimulateHttps on
Reregister mod_osso on the single sign-on middle tier. This step configures mod_osso to use the proxy host name instead of the actual host name. To learn how to run the registration tool, see "Registering mod_osso" in Chapter 4.
Update the Distributed Cluster Management schema:
ORACLE_HOME/dcm/bin/dcmctl updateconfig
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
If you are deploying more than one single sign-on middle tier, repeat steps 2 through 4 on each additional middle tier.
Log in to the single sign-on server, using the single sign-on login URL:
http://proxy_host_name:proxy_port/pls/orasso/
This URL takes you to the single sign-on home page. If you are able to log in, you have configured the proxy correctly.
The single sign-on database uses the user nickname to store and reference user data for external applications. In the event that the nickname attribute value changes in Oracle Internet Directory, users are forced to reenter their credentials when they log in with a new user ID. For their convenience, changes to their user names can be automatically synchronized between the directory and the single sign-on database. This synchronization mechanism, offered through Oracle Directory Integration and Provisioning, also deletes the external application data from the single sign-on database when a user's entry is deleted from the directory.
To synchronize nickname changes between the directory and the single sign-on database, follow these steps:
Start the Oracle Directory Integration and Provisioning server. For instructions, see the chapter about administration tools in Oracle Identity Management Integration Guide.
Load the synchronization package. First, navigate to ORACLE_HOME/sso/admin/plsql/sso; then connect to the single sign-on schema:
sqlplus orasso/password
See Appendix B to learn how to obtain the orasso password.
Run these packages in the order listed:
SQL> @ssodip.sql SQL> @ssodip.pks SQL> @ssodip.pkb
Register the single sign-on profile with Oracle Internet Directory. You do this by running the Provisioning Subscription Tool (oidprovtool):
ORACLE_HOME/bin/oidprovtool operation=create ldap_host=oid_host ldap_port=oid_port ldap_user_dn=cn=orcladmin ldap_user_password=orcladmin_password schedule=synchronization_interval_in_seconds organization_dn=realm_DN application_dn=orclApplicationCommonName=ORASSO_SSOSERVER,cn=SSO, cn=Products,cn=OracleContext interface_name=LDAP_NTFY interface_type=PLSQL interface_connect_info=sso_database_host:sso_database_port:sso_ database_SID:orasso:orasso_schema_password event_subscription=USER:user_search_base_for_realm:ADD(attribute_type) event_subscription=USER:user_search_base_for_realm:MODIFY(attribute_type) event_subscription=USER:user_search_base_for_realm:DELETE
If changes to the realm occur, reregister the profile. The user search base may change. Or the nickname attribute type. For example, the uid attribute may replace the cn attribute.
For help using oidprovtool, see the syntax appendix in Oracle Internet Directory Administrator's Guide.
Give the Oracle Directory Integration and Provisioning server privileges to proxy as orasso. This involves modifying the orasso entry in the directory.
First create an LDIF file:
dn: orclApplicationCommonName=ORASSO_SSOSERVER,cn=SSO,cn=Products, cn=OracleContext changetype: modify add: orclaci orclaci: access to entry by group="cn=odisgroup,cn=odi,cn=oracle internet directory" (proxy)
Load the LDIF file into the directory as the super user cn=orcladmin.
Make sure that the Oracle Directory Integration and Provisioning server is running.
Depending upon how synchronization is scheduled, there may be a lapse between the time changes are made in the directory and the time they are synchronized with the single sign-on server. Because of this lapse, users whose user IDs have changed gain access to external applications only when synchronization finally occurs.
