Previous	Next		Contents	Index	Glossary

Synchronization with OID enables Oracle Workflow to do the following:

• Assign ownership of work items and send notifications to users defined in OID.

• Synchronize with other external user directories that are synchronized with OID.

• Participate in single sign-on through LDAP external authentication with Oracle Application Server Single Sign-On Server, if you have installed Oracle Application Server. With single sign-on, a user who is logged into any participating Oracle Application Server component is automatically authenticated when accessing any other participating component and does not need to log in again.

Attention: To implement single sign-on integration, you must install Oracle Workflow with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.

For more information about leveraging the Oracle Identity Management infrastructure, see: Oracle Workflow Security.

Context: You need to perform this step only once.

Oracle Internet Directory

LDAP is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to communicate. LDAP was conceived as an internet-ready, lightweight implementation of the International Standardization Organization (ISO) X.500 standard for directory services. It requires a minimal amount of networking software on the client side, which makes it particularly attractive for internet-based, thin client applications.

The advantages of OID include:

• Scalability - Oracle Internet Directory exploits the strengths of the Oracle Database, enabling support for terabytes of directory information. In addition, such technologies as multithreaded LDAP servers and database connection pooling allow it to support thousands of concurrent clients with subsecond search response times.

Oracle Internet Directory also provides data management tools, such as Oracle Directory Manager and a variety of command-line tools, for manipulating large volumes of LDAP data.

• High availability - Oracle Internet Directory is designed to meet the needs of a variety of important applications. For example, it supports full, multimaster replication between directory servers: If one server in a replication community becomes unavailable, then a user can access the data from another server. Information about changes made to directory data on a server is stored in special tables on the Oracle Database. These are replicated throughout the directory environment by Oracle Replication, a robust replication mechanism.

Oracle Internet Directory also takes advantage of all the availability features of the Oracle Database. Because directory information is stored securely in the Oracle Database, it is protected by the backup capabilities of the database. Additionally, the Oracle Database, running with large datastores and heavy loads, can recover from system failures quickly.

• Security - Oracle Internet Directory offers comprehensive and flexible access control. An administrator can grant or restrict access to a specific directory object or to an entire directory subtree. Moreover, Oracle Internet Directory implements three levels of user authentication: anonymous, password-based, and certificate-based using Secure Socket Layer (SSL) Version 3 for authenticated access and data privacy.

• Synchronization with other directories - Oracle Internet Directory includes the Oracle Directory Integration platform that enables you to synchronize with other enterprise repositories, including third-party LDAP directories.

See Also

Oracle Application Server Single Sign-On

Attention: To implement single sign-on integration for Oracle Workflow, you must install Oracle Workflow with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.

Oracle Application Server Single Sign-On provides the following benefits:

• Ease of administration and reduced administrative costs, because user names and passwords can be stored and maintained outside of any particular application and shared across the enterprise

• Convenient login experience, because users do not need to maintain a separate username and password for each application they access

• Increased security, because when the password is only required once, users are less likely to use simple, easy-to-remember passwords or write them down

Partner applications support a single sign-on mechanism that enables them to accept a user's username and password as validated by the Login Server. A partner application delegates its authentication to the Login Server. If a partner application is registered with the Login Server, users can log into it using the single sign-on mechanism.

With mod_osso, an Oracle module that enables single sign-on, Oracle HTTP Server becomes a partner application of the Login Server. Oracle Workflow uses Oracle HTTP Server as its Web server. If you implement Oracle Internet Directory/Single Sign-On integration, Oracle Workflow participates in single sign-on by using mod_osso to authenticate access to its secured web pages.

When a user first tries to access a secured Workflow web page, the Workflow security package WFA_SEC checks the CGI environment variable REMOTE_USER for user information. If the user is not already logged in to Oracle Workflow or another Oracle Application Server Single Sign-On participating application, the user will be prompted to log in before the page appears.

Note: The WFA_SEC package must be loaded as a post-install step if you choose to implement Oracle Internet Directory/Single Sign-On integration. For more information, see your installation documentation.

To set the variable REMOTE_USER, Oracle HTTP Server internally calls to mod_osso. Acting as an Oracle Application Server Single Sign-On partner application, mod_osso transparently redirects the user to the Login Server to obtain authentication credentials, if no application cookie is present.

The Login Server performs the following steps:

• Prompts the user for the user name and password, if no login cookie is present.

• Authenticates the user by means of the user name and password, using external repository authentication that relies on an LDAP-compliant directory, specifically Oracle Internet Directory. The Login Server binds to OID and then looks up the user credentials stored in the directory.

• Stores an encrypted login cookie on the authenticated client.

• Transparently redirects the user to the partner application, mod_osso, by using a URL with an encrypted parameter containing the user's identity.

• Decrypts the parameter.

• Identifies the user.

• Establishes its own session management (for example, determining what, if any, access privileges to grant to the user).

• Sets a partner application cookie so that subsequent user access does not require a redirect to the Login Server.

• Presents the requested application page to the user.

To guard against eavesdropping, the Login Server can send the login cookie to the client browser over an encrypted SSL channel.

The login cookie expires with the session, either at the end of a time interval specified by the administrator, or when the user exits the browser. The login cookie is never written to disk.

Note: To log out of a partner application and log in as another user, the user must also log out of the Login Server session. Otherwise, the authentication request returns the partner application to the logged in state of the previous user.

See Also

Oracle Identity Management Application Developer's Guide

Oracle Internet Directory Synchronization

Note: OID integration includes only individual users, not user groups. Workflow roles are not maintained through OID.

   To Synchronize Workflow Directory Services with OID

1. During installation, use the Workflow Configuration Assistant to choose to integrate with OID. You enter LDAP preferences in the Workflow Configuration Assistant, which are then stored as global workflow preferences. After installation, you can use the Global Preferences page to verify that the following preferences are set to the appropriate information for your OID installation, and optionally modify these settings. See: Setting Global User Preferences.

• LDAP Host

• LDAP Port

• LDAP User Name

• LDAP Password

• LDAP Changelog Base Directory

• LDAP User Base Directory

Note: If you choose to integrate with OID during installation, Workflow directory service views that support this integration are automatically implemented for you. See: Integrating Oracle Workflow Directory Services with Oracle Internet Directory.

2. Ensure that the PL/SQL package named DBMS_LDAP is loaded in your database. This package contains the functions and procedures which can be used to access data from LDAP servers and is required for LDAP synchronization.

For standalone Oracle Workflow, if you choose to integrate with OID by entering LDAP preferences in the Workflow Configuration Assistant, this package should be loaded as a pre-installation step. For more information, see the installation documentation for the software with which you installed Oracle Workflow.

3. For single sign-on integration, ensure that the Database Access Descriptor for Oracle Workflow is protected in the mod_osso configuration file. For standalone Oracle Workflow, if you choose to integrate with OID by entering LDAP preferences in the Workflow Configuration Assistant, mod_osso configuration is automatically performed for you during installation. For more information, see the installation documentation for the software with which you installed Oracle Workflow.

Attention: To implement single sign-on integration, you must install Oracle Workflow with Oracle Application Server, and you must use a version of the Oracle Database that is certified with your version of Oracle Application Server.

4. If you choose to integrate with OID by entering LDAP preferences in the Workflow Configuration Assistant, the Workflow Configuration Assistant performs an initial synchronization for you by running the WF_LDAP.Synch_all( ) API. This function retrieves all the existing user information from OID, based on the LDAP directory information specified in the global workflow preferences, and raises the oracle.apps.global.user.change event. Predefined subscriptions to this event create new users in the WF_LOCAL_ROLES table if necessary and load the user information into the WF_LOCAL_ROLES table.

Because WF_LDAP.Synch_all( ) retrieves information for all users stored in OID, this function should be used only once during setup. If necessary, however, you can also run WF_LDAP.Synch_all( ) as required for recovery or cleanup.

5. Subsequently, you must maintain the synchronization between your Workflow directory service and OID by retrieving and loading only changed OID user information. It is recommended that you update the user information every ten minutes.

You can use either WF_LDAP.Synch_changes( ) or WF_LDAP.Schedule_changes( ) to retrieve changed user information from OID. WF_LDAP.Synch_changes( ) identifies LDAP user changes in OID, including creation, modification, and deletion, by querying the LDAP change log records. The function connects to OID based on the LDAP directory information specified in the global workflow preferences. If there is a change, the function retrieves the user information from OID and raises the oracle.apps.global.user.change event. Predefined subscriptions to this event create new users in the WF_LOCAL_ROLES table if necessary and load the user information into the table. You can use WF_LDAP.Synch_changes( ) to perform a single update.

To continue updating user information periodically, use WF_LDAP.Schedule_changes( ). This procedure submits a database job using the DBMS_JOB utility to run WF_LDAP.Synch_changes( ) repeatedly at an interval that you specify. The default interval, which is also the recommended frequency to check for updates, is ten minutes.

You can create a script to run WF_LDAP.Schedule_changes( ). For example, to run the API at an interval of ten minutes, create a SQL file with the following commands:

		declare

		begin

		  wf_ldap.schedule_changes(0,0,10);

		end;

		/

Then run SQL*Plus and load your new script to the database.

Note: You must terminate the running of any WF_LDAP APIs before changing your LDAP setup, such as by migrating to a different LDAP server.

Attention: If you implement OID integration, you must maintain your users only through OID. You must not create ad hoc users in the WF_LOCAL_ROLES table, because you risk discrepancies in your user information and unpredictable results if you use any tool other than OID to maintain users after integrating with OID. Consequently, if you implement OID integration, you must not use the CreateAdHocUser( ), SetAdHocUserStatus( ), SetAdHocUserExpiration( ), or SetAdHocUserAttr( ) APIs in the WF_DIRECTORY package.

You can still use ad hoc roles, however, since Workflow roles are not maintained through OID.

See Also

Workflow LDAP APIs, Oracle Workflow API Reference

User Entry Has Changed Event, Oracle Workflow Developer's Guide

Managing Job Queues, Oracle Administrator's Guide

Workflow Directory Service APIs, Oracle Workflow API Reference