|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) B14078-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) B14078-02 |
|
|
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 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 9-1 shows the first type of installation. Figure 9-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 9-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 9-1 Default Single Sign-On Installation: One Computer
Figure 9-2 Single Sign-On Installation: Two Computers
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.
This section contains these topics:
You may deploy two or more single sign-on middle tiers in one of two ways: as a cluster or manually. The first method recommends itself for ease of installation. The OracleAS installer clusters the single sign-on nodes automatically around one distributed cluster management (DCM) database. DCM is the component that replicates cluster configuration information among all nodes in a cluster whenever changes to that configuration occur on any one node. This configuration is known as "OracleAS Cluster (Identity Management)" because middle-tier components such as OracleAS Single Sign-On are clustered and configured identically across nodes.
If the DCM database fails, however, all single sign-on nodes fail. If you want to avoid this dependency, configure the middle tiers manually—both with their own DCM database.
The configuration steps for a manual deployment appear in the sections immediately following.
|
See Also: To learn how to install a cluster, see the chapter about OracleAS Cluster (Identity Management) in Oracle Application Server Installation Guide. More specifically, refer to the following:
|
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.
|
Notes:
|
Figure 9-3 shows two single sign-on middle tiers configured to use a single instance of Oracle Internet Directory.
Figure 9-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 only. When the Oracle Universal Installer asks you to name the directory server associated with these 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 "Static Port Numbers" in Chapter 4 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 httpd.conf file on both single sign-on middle tiers must be modified to reflect this change. This file can be 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: If multiple ports are listed inhttpd.conf, the effective port must appear last.
|
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 following steps. You can place them at the end of httpd.conf. Ordering is not important.
In httpd.conf on both middle tiers, enter the following line:
LoadModule certheaders_module libexec/mod_certheaders.so
If you are using OracleAS Web Cache as a load balancer, enter the following line:
AddCertHeader HTTPS
If you are using a hardware load balancer, enter the following line:
SimulateHttps on
Synchronize system clocks between both middle tiers.
Execute the following command to update the Distributed Configuration 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 hardware such as BigIP, Alteon, or Local Director or software such as 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 executed in the following way.
UNIX:
$ORACLE_HOME/sso/bin/ssocfg.sh http sso.mydomain.com 80
Windows NT/2000:
%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 4443 and http with https.
Reregister mod_osso on the single sign-on middle tiers
On both middle tier computers, reregister mod_osso as the partner application sso.mydomain.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. Include $ORACLE_HOME/jdk/bin in the PATH variable.
Run the registration script. For the URLs, be sure to substitute values appropriate for your installation. The script creates a partner application called sso.mydomain.com.
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar -oracle_home_path orcl_home_path -site_name site_name -config_mod_osso TRUE -mod_osso_url mod_osso_url -u userid [-virtualhost] [-update_mode CREATE | DELETE | MODIFY] [-config_file config_file_path] [-admin_id adminid] [-admin_info admin_info]
For a description of command parameters, see "Registering mod_osso" in Chapter 4.
Restart the middle tier at sso1.mydomain.com. For instructions, see "Stopping and Starting the Single Sign-On Middle Tier" in Chapter 2.
To reregister 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
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 Configuration Management repository with the file copy. You do this by running the following command on sso2.mydomain.com:
$ORACLE_HOME/Apache/Apache/bin/ssotransfer $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
|
Note: The ssotransfer command should not be used to synchronize the Distributed Configuration 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 (SSL and non-SSL)" in Chapter 4. |
Restart the middle tier at sso2.mydomain.com. For instructions, see "Stopping and Starting the Single Sign-On Middle Tier" in Chapter 2.
If Oracle Delegated Administration Services is installed, change its base URL, using Oracle Directory Manager:
Start the tool:
$ORACLE_HOME/bin/oidadmin
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.
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 chapter about this topic in Oracle Application Server High Availability Guide. The chapter shows how to configure 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 9-4 depicts what this geographically distributed system looks like once it is deployed.
Figure 9-4 A Highly Available, Geographically Distributed Single Sign-On System
The geographically dispersed single sign-on system shown in Figure 9-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 the appendix about deploying Oracle Identity Management with multimaster replication in Oracle Application Server High Availability 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 9-5 illustrates the process.
Figure 9-5 Multimaster Replication Architecture
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:
To install and configure a multimaster replication group, see the appendix about this topic in Oracle Application Server High Availability Guide. 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 9-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 9-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 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 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" in Chapter 7 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 Configuration 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.
