Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Data Integrator
11g Release 1 (11.1.1)

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

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

24 Managing the Security in Oracle Data Integrator

This chapter describes how to set up security in Oracle Data Integrator. An overview of Oracle Data Integrator security concepts and components is provided.

This chapter contains the following sections:

24.1 Introduction to Oracle Data Integrator Security

Oracle Data Integrator security is used to secure any action performed by authenticated users against the design-time and run-time artifacts and components of Oracle Data Integrator.

Security is built around users and profiles, to which security administrators grant methods (edit, delete, and so forth) on objects types (projects, models, interfaces, and so forth) or on specific object instances (Data warehouse Project, ODS Project, and so forth).

All the security information for Oracle Data Integrator is stored in the master repository.

This section contains the following topics:

24.1.1 Objects, Instances and Methods

An Object is a representation of a design-time or run-time artifact handled through Oracle Data Integrator. For example, agents, models, datastores, scenarios, interfaces and even repositories are objects. Specific objects have a double name (Agent/Context, Profile/Method, and so forth). These objects represent links between objects. These links are also objects. For instance, Agent/Context corresponds to a physical/logical agent association made through the contexts. Privileges on this object enable to change this association in the topology.

An Instance is a particular occurrence of an object. For example, the Datawarehouse project is an instance of the Project object.

A Method is an action that can be performed on an object. Each object has a predefined set of methods.

Note:

The notions of object instance and method in Oracle Data Integrator are similar to the concepts used in Object-Oriented Programming.

WARNING:

Although they appear in the Security Navigator, objects and methods are predefined in Oracle Data Integrator and should not be altered.

24.1.2 Profiles

A Profile contains a set of privileges for working with Oracle Data Integrator. One or more profiles can be assigned to a user to grant the sum of these privileges to this user.

A Profile Method is an authorization granted to a profile on a method of an object type. Each granted method allows a user with this profile to perform an action (edit, delete, and so forth) on an instance of an object type (project, model, datastore, and so forth).

Methods granted to a profile appear under this profile in the Profiles accordion of the Security Navigator. When a method does not appear for a given profile, this profile does not have access to this method.

A method can be granted as a generic or non-generic privilege:

  • A method granted as a generic privilege is granted by default on all the instances of this object.

  • A method granted as a non-generic privilege is not granted by default on all object instances, but may be granted per instance.

Generic vs. Non-Generic profiles

Generic profiles have the Generic privilege option selected for all object methods. This implies that a user with such a profile is by default authorized for all methods of all instances of an object to which the profile is authorized.

Non-Generic profiles are not by default authorized for all methods on the instances since the Generic privilege option is not selected for all object methods. The administrator must grant the user the rights on the methods for each instance.

If the security administrator wants a user to have the rights on no instance by default, but wishes to grant the rights by instance, the user must be given a non-generic profile.

If the security administrator wants a user to have the rights on all instances of an object type by default, the user must be given a generic profile.

Built-In Profiles

Oracle Data Integrator has some built-in profiles that the security administrator can assign to the users he creates.

Table 24-1 shows the built-in profiles delivered with Oracle Data Integrator.

Table 24-1 Built-In Profiles

Profile Name Description

CONNECT

Profile granted with the basic privileges to connect Oracle Data Integrator. It should be granted with another profile.

DESIGNER

Profile granted with privileges to perform development operations. Use this profile for users who will work mainly on projects.

NG_DESIGNER

Non-generic version of the DESIGNER profile.

METADATA_ADMIN

Profile granted with privileges to manage metadata. Use this profile for users that will work mainly on models.

NG_METADATA_ADMIN

Non-generic version of the METATADA_ADMIN profile.

OPERATOR

Profile granted with privileges to manage run-time objects. Use this profile for production users.

REPOSITORY_EXPLORER

Profile granted with privileges to view objects. Use this profile for users who do not need to modify objects.

NG_REPOSITORY_EXPLORER

Non-generic version of the REPOSITORY_EXPLORER profile.

SECURITY_ADMIN

Profile granted with privileges to edit security. Use this profile for security administrators.

TOPOLOGY_ADMIN

Profile granted with privileges to edit the Topology. Use this profile for system or Oracle Data Integrator administrators.

VERSION_ADMIN

Profile granted with privileges to create, restore and edit versions and solutions. Use this profile for project managers, or developers who are entitled to perform version management operations.

NG_VERSION_ADMIN

Non-generic version of the VERSION_ADMIN profile.


Note:

Built-in profiles should preferably not be changed, as they evolve to secure the new feature of Oracle Data Integrator. If you want to customize your own profiles or existing profiles, it is recommended to create duplicates of the built-in profiles and customize these copies.

24.1.3 Users

A User is an Oracle Data Integrator user, and corresponds to the login name used to connect to a repository.

A user inherits the following privileges:

  • All the privileges granted to its various profiles

  • Privileges on objects and/or instances given to this user

A User Method is a privilege granted to a user on a method of an object type. Each granted method allows the user to perform an action (edit, delete, and so forth) on instances of an object type (project, model, datastore, and so forth). These methods are similar to the Profiles Methods, applied to users.

It is possible to grant users with privileges on instances on specific work repositories where these instances exist. For example, you may grant a developer user with the edit privilege on the LOAD_DATAWAREHOUSE scenario on the a DEVELOPMENT repository and not on a PRODUCTION repository.

An authorization by Object Instance is granted to a user on an object instance. It allows to grant to this user certain methods of this object instance.

The presence in a user's tree of an authorization by object instance for a given instance shows that the user is granted specific privileges on the object methods for the given instance (these privileges are specified in the Object Instance editor). If an instance is not visible in the tree of the user instances, then the User Method or Profile Method privileges for the object type apply.

As an instance may be replicated over the different work repositories that are attached to the master repository, authorizations by object instances may be defined for one, multiple or all your work repositories attached to this master repository. For example, a LOAD_DATAWAREHOUSE scenario instance may be replicated (using for example versioning) in the DEVELOPMENT, TEST, and PRODUCTION repositories. Privileges on the instance will change depending on the repository.

For example, it is common to replicate projects from a Development repository to a Test repository. A developer may be granted edit privileges for his project in the Development repository, but not on the Test repository. On the Test repository, he will only be granted with view privileges on the project.

24.2 Setting up a Security Policy

This section explains how to use the different security concepts to enforce security in Oracle Data Integrator.

This section contains these topics:

24.2.1 Security Policy Approach

There are two main approaches for defining the security in Oracle Data Integrator:

  • The strongly secured approach, where users have no default authorizations on objects. This approach uses only non-generic profiles. The security administrator must grant the users authorizations on object instances. This policy is complex to configure, as it requires to manage privileges by instance.

  • The generic approach, where users inherit the privileges of the profiles they have. This policy is suitable for most cases, and is simple to configure.

To implement a strongly secured approach:

  1. Create the users.

  2. Give the users non-generic profiles (built-in or customized).

  3. Grant the users privileges on object instances after these are created. This operation must be repeated for every new instance.

To implement a generic approach:

  1. Create the users.

  2. Give the users the generic profiles (built-in or customized).

Note:

It is possible to combine the two approaches by using simultaneously generic and non generic profiles. For example, by using DESIGNER and NG_METADATA_ADMIN for the users, you would manage projects is a generic approach and models in a strongly secured approach.

24.2.2 Managing Profiles

You can create, delete or duplicate profiles to customize the profiles assigned to users.

24.2.2.1 Creating a New Profile

To create a Profile:

  1. In Security Navigator expand the Profiles accordion.

  2. Click New Profile in the toolbar of the Profiles accordion.

  3. In the Name field, enter a name for your profile.

  4. From the File main menu, select Save.

The new profile appears.

24.2.2.2 Duplicating a Profile

To duplicate a Profile:

  1. In Security Navigator expand the Profiles accordion.

  2. Select the profile that you want to duplicate from the list of profiles.

  3. Right-click and select Duplicate.

A new profile (copy of the original profile) appears.

24.2.2.3 Deleting a Profile

To delete a Profile:

  1. In Security Navigator expand the Profiles accordion.

  2. Select the profile that you want to delete from the list of profiles.

  3. Right-click and select Delete.

  4. Click OK in the Confirmation dialog.

The profile disappears from the list. All users granted with this profile lose the privileges attached to this profile.

24.2.3 Managing Users

You can create and delete users, assign and remove built-in or customized profiles to users.

24.2.3.1 Creating a New User

To create a User:

  1. In Security Navigator expand the Users accordion.

  2. Click New User in the toolbar of the Users accordion.

  3. In the Name field, enter a name for your user.

  4. Provide the Initials for this user.

  5. Do one of the following:

    • If using Internal Authentication, click Enter the Password and provide a password for this user.

    • If using External Authentication, click Retrieve GUID to associate the new user with a user from the external authentication service. The user name in Oracle Data Integrator must match the user login in the external authentication storage. If a match is found, an Global Unique ID appears in the External GUID field.

  6. From the File main menu, select Save.

The new user appears in the Users accordion.

24.2.3.2 Assigning a Profile to a User

To assign a Profile to a User:

  1. In Security Navigator expand the Users and the Profiles accordions.

  2. Select the profile that you want to assign, then drag it on the user you want to assign it to.

  3. Click OK in the Confirmation dialog.

The profile appears under the Profiles of this user. The user is immediately granted the privileges attached to this profile.

24.2.3.3 Removing a Profile from a User

To remove a Profile to a User:

  1. In Security Navigator expand the Users accordions.

  2. Expand the Profiles node under the user.

  3. Right-click the profile to be removed.

  4. Select Delete.

  5. Click OK in the Confirmation dialog.

The profile disappears from the Profiles of this user. All privileges granted to this user via this profile are removed.

24.2.3.4 Deleting a User

To delete a User:

  1. In Security Navigator expand the Users accordion.

  2. From the list of users, select the user that you want to delete.

  3. Right-click and select Delete.

  4. Click OK in the Confirmation window.

The user disappears from the list.

24.2.4 Managing Privileges

After creating users or profiles, it is possible to grant privileges to these users and profiles. You can grant Profile Methods and User Methods that apply to object types, and Authorizations by Object Instances (for users only) that apply to specific object instances.

24.2.4.1 Granting a Profile Method or User Method

To grant a Profile Method or User Method:

  1. In Security Navigator expand the Users or Profiles accordion.

  2. Expand the Objects accordion, and expand the node of the object for which you want to grant a privilege.

  3. Select the method that you want to grant, then drag it on the user or profile you want to grant the method to.

  4. Click OK in the Confirmation window.

The Method is granted to the user or the profile. It appears under the Objects node of this user or under the profile.

Note:

You can grant privileges on all the methods of an object by dragging the object itself on the user or profile instead of dragging one of its methods.

24.2.4.2 Revoking a Profile Method or User Method

To revoke a Profile Method or User Method:

  1. In Security Navigator expand the Users or Profiles accordion.

  2. Expand the Profiles or the Objects node under the user for which you want you revoke privileges, then expand the object whose method needs to be revoked.

  3. Right-click the method and then select Delete.

  4. Click OK in the Confirmation dialog.

The Method is revoked from the user or the profile. It disappears from the methods list under the Objects node of this user or profile.

24.2.4.3 Granting an Authorization by Object Instance

To grant an authorization by object instance to a user:

  1. In Security Navigator expand the Users accordion.

  2. In the Designer, Operator or Topology Navigator, expand the accordion containing the object onto which you want to grant privileges.

  3. Select this object, then drag it on the user in the Users accordion. The authorization by object instance editor appears. This editor shows the list of methods available for this instance and the instances contained into it. For example, if you grant privileges on a project instance, the folders, interfaces, and so forth contained in this project will appear in the editor.

  4. Fine-tune the privileges granted per object and method. You may want to implement the following simple privileges policies on methods that you select from the list:

    • To grant all these methods in all repositories, click Allow selected methods in all repositories.

    • To deny all these methods in all repositories, click Deny selected methods in all repositories.

    • To grant all these methods in certain work repositories, click Allow selected methods in selected repositories, then select the repositories from the list.

  5. From the File main menu, select Save.

Note:

Only certain objects support the authorization by object instance. These object types are listed under the Instances node for each user.

Methods for which the user has generic privileges are not listed in the Object Instance Editor.

24.2.4.4 Revoking an Authorization by Object Instance

To revoke an authorization by object instance from an user:

  1. In Security Navigator expand the Users accordion.

  2. Expand the Instances node under the user for which you want you revoke privileges.

  3. Right-click the instance from which you want to revoke an authorization, and then select Delete.

  4. Click OK in the Confirmation dialog.

The authorizations on this object instance are revoked from the user.

Note:

You can also revoke privileges per method by editing the Authorization by Object instance and denying certain methods to this user. If, after this operation, the user no longer has any privilege on an instance, the instance automatically disappears from the tree in Security Manager.

24.2.4.5 Cleaning up Unused Authorizations

Authorizations by object instance are stored in the master repository. However, if objects are deleted from all work repositories, the authorization are not necessarily deleted. You may wish to retain certain unused authorizations if they refer, for example, to objects currently stored in an exported file or in a stored solution.

The Security Clean-up Tool should be used periodically to remove these unused authorizations from the master repository. Unused authorizations are removed if they refer to objects that do not exist in the master repository or in any work repository.

Note:

All work repositories attached to the master repository must be accessible in order to check the existence of the objects in these repositories

To clean up unused authorizations:

  1. From the Security Navigator toolbar menu, select Clean Up Security Settings... The Security Clean-up Tool dialog appears.

  2. On the Cleanable tab, select Clean for the cleanable security settings you wish to remove. The security settings that cannot be removed are shown on the Non-cleanable tab.

  3. Click OK to cleanup the selected security settings.

24.3 Advanced Security

This section explains how to improve security in Oracle Data Integrator by using some of the advanced security features.

This section contains the following topics:

24.3.1 Setting Up External Password Storage

Oracle Java Platform Security (JPS) offers the standard Java Security Model services for authentication and authorization.

Oracle Data Integrator stores by default all security information in the master repository. This password storage option is called Internal Password Storage.

Oracle Data Integrator can optionally use JPS for storing critical security information. When using JPS with Oracle Data Integrator, the data server passwords and context passwords are stored in the JPS Credential Store Framework (CSF). This password storage option is called External Password Storage.

Note:

When using External Password Storage, other security details such as user names, password, and privileges remain in the master repository. It is possible to externalize the authentication and have users and password stored in an Identity Store using External Authentication. See Section 24.3.2, "Setting Up External Authentication" for more information.

To use the external password storage option, you need to install a WebLogic Server instance configured with JPS and all Oracle Data Integrator components (including the run-time Agent) need to have access to the remote credential store. See "Configuring a JavaEE Application to Use OPSS" in the Oracle Fusion Middleware Application Security Guide for more information.

24.3.1.1 Setting the Password Storage

There are four ways to set or modify the password storage:

24.3.1.2 Switching the Password Storage

Switching the password storage of the Oracle Data Integrator repository changes how data servers and contexts passwords are stored. This operation must be performed by a SUPERVISOR user.

Use the Switch Password Storage wizard to change the password storage options of the data server passwords.

Before launching the Switch Password Storage wizard perform the following tasks:

  • Disconnect Oracle Data Integrator Studio from the repository.

  • Shut down every component using the Oracle Data Integrator repository.

To launch the Switch Password Storage wizard:

  1. From the ODI main menu, select Password Storage > Switch...

  2. Specify the login details of your Oracle Data Integrator master repository as defined when Connecting to the Master Repository.

  3. Click Next.

  4. Select the password storage:

    • Select Internal Password Storage if you want to store passwords in the Oracle Data Integrator repository.

    • Select External Password Storage if you want use JPS Credential Store Framework (CSF) to store the data server and context passwords.

      If you select External Password Storage, you must provide the MBean Server Parameters to access the credential store as described in Table 24-2 and then click Test Connection check the connection to the MBean Server.

      Table 24-2 MBean Server Parameters

      Host

      MBeans Server Host, for example: mymachine.oracle.com

      JMX Port

      MBeans Server Port, for example: 7001

      User

      MBeans Server User Name, for example: weblogic

      Password

      MBeans Server Password, for example: weblogic


  5. Click Finish.

The password storage options have been changed. You can now re-connect to the Oracle Data Integrator repository.

24.3.1.3 Recovering the Password Storage

Oracle Data Integrator offers a password recovery service that should be used only in case of an external password storage crash. Using this procedure, password storage is forced to Internal Password Storage as the external storage is no longer available. This operation should be performed by a Supervisor user.

WARNING:

When performing a password storage recovery, passwords for context, data servers, jdbc password of the work repository and ESS related passwords are lost and need to be re-entered manually in Topology Navigator.

Use the Recover Password Storage wizard to start the password recovery.

To launch the Recover Password Storage wizard:

  1. From the ODI main menu, select Password Storage > Recover...

  2. Specify the login details of your Oracle Data Integrator master repository defined when Connecting to the Master Repository.

  3. Click Finish.

  4. Re-enter manually data server and context passwords. Refer to Chapter 4, "Setting-up the Topology" for more information.

24.3.2 Setting Up External Authentication

Oracle Platform Security Services (OPSS) is a standards-based and portable security framework for Java applications. OPSS offers the standard Java Security Model services for authentication and authorization.

Oracle Data Integrator stores all user information as well as users' privileges in the master repository by default. When a user logs to Oracle Data Integrator, it logs against the master repository. This authentication method is called Internal Authentication.

Oracle Data Integrator can optionally use OPSS to authenticate its users against an external Identity Store, which contains enterprise user and passwords. Such an identity store is used at the enterprise level by all applications, in order to have centralized user and passwords definitions and Single Sign-On (SSO). In such configuration, the repository only contains references to these enterprise users. This authentication method is called External Authentication.

Note:

When using External Authentication, only users and passwords are externalized. Oracle Data Integrator privileges remain within the repository. Data servers and context passwords also remain in the master repository. It is possible to externalize data server and context passwords, using the External Password Storage feature. See Section 24.3.1, "Setting Up External Password Storage" for more information.

24.3.2.1 Configuring ODI Components for External Authentication

To use the External Authentication option, you need to configure an enterprise Identity Store (LDAP, Oracle Internet Directory, and so forth), and have this identity store configured for each Oracle Data Integrator component to refer by default to it.

Oracle Data Integrator Studio

The configuration to connect and use the identity store is contained in an OPSS Configuration file called jps-config.xml file. See "Configuring a JavaEE Application to Use OPSS" in the Oracle Fusion Middleware Application Security Guide for more information.

Copy this file into the ODI_HOME/client/odi/bin/ directory. The Studio reads the identity store configuration and authenticates against the configured identity store.

If you want to locate this file in a different location, edit the ODI_HOME/client/odi/bin/odi.conf file and edit the option that sets the location of the configuration file. This option is set in the following line:

AddVMOption -Doracle.security.jps.config=./jps-config.xml

Standalone Agent

The configuration to connect and use the identity store is contained in an OPSS Configuration File called jps-config.xml file. Refer to the Oracle Fusion Middleware Application Security Guide for more information.

Copy this file in the ODI_HOME/agent/bin/ directory. The agent and the command line scripts will authenticate against the configured identity store.

Java EE Components

Oracle Data Integrator components deployed in a container (Java EE Agent, Oracle Data Integrator Console) do not require a specific configuration. They use the configuration of their container.

See "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g" in the Oracle Fusion Middleware Application Security Guide for more information on OPSS configuration in a Java EE context.

24.3.2.2 Setting the Authentication Mode

There are two ways to set or modify the password storage:

24.3.2.3 Switching the Authentication Mode

Switching the authentication mode of the Oracle Data Integrator repository changes the way users authenticate. This operation must be performed by a Supervisor user.

WARNING:

When switching from an External to Internal authentication, user passwords are not copied from the identity store to the repository. The passwords are nullified. All the user accounts are marked as expired and must be reactivated by a SUPERVISOR that is created during the switch.

When switching from Internal to External authentication, the users that exist in the repository and match a user in the identity store are automatically mapped. Users that do not match a user in the identity store are disabled. A Supervisor must edit the users so that their name has a match in the identity store.

The context passwords are lost. Passwords for data servers, jdbc password of the work repository, and ESS related passwords are moved from a credential store to another.

Use the Switch Authentication Mode wizard to change the user authentication mode.

Before launching the Switch Authentication Mode wizard perform the following tasks:

  • Disconnect Oracle Data Integrator Studio from the repository.

  • Shut down every component using the Oracle Data Integrator repository.

To use the Switch Authentication Mode wizard:

  1. From the ODI main menu, select Switch Authentication Mode.... The Switch Authentication Mode wizard appears.

  2. Specify the JDBC connectivity details of your Oracle Data Integrator master repository as defined when Connecting to the Master Repository.

  3. Click Next.

  4. The next action varies depending on the current Authentication Mode in use:

    • If currently using Internal Authentication, you are prompted to switch to external authentication.

    • If currently using External Authentication, you are prompted to switch to internal authentication. You must provide and confirm a password for the SUPERVISOR user that the wizard will automatically create in the repository.

  5. Click Finish.

The Authentication mode is changed.

  • If you have switched from external to internal authentication, you can now re-connect to the Oracle Data Integrator repository as SUPERVISOR, with the password you have provided in the wizard. Once connected, you can edit each user to reactivate it and set a password for this user.

  • If you have switched from internal to external authentication, you can now re-connect to the Oracle Data Integrator repository as one of the users with supervisor privileges, and re-enable the Oracle Data Integrator users that have been disabled during the switch.

Reactivating Users After Switching to Internal Authentication

To reactivate a User:

  1. In Security Navigator expand the Users accordion.

  2. Select the user that you want to reactivate from the list of users.

  3. Right-click and select Edit. The User editor appears.

  4. Un-select Allow Expiration Date.

  5. If you want to set a password for this user, click Change Password and enter the new password for this user.

  6. From the File main menu, select Save.

Re-Enable Users After Switching to External Authentication

To re-enable a User:

  1. In Security Navigator expand the Users accordion.

  2. Select the user that you want to re-enable from the list of users.

  3. Right-click and select Edit. The User editor appears.

  4. Enter in the Name field a user name that matches the login of an enterprise user in the identity store.

  5. Click Retrieve GUID. If the user name has a match in the identity store, this external user's GUID appear in the External GUID field.

  6. From the File main menu, select Save.

24.3.2.4 Configuring the OPSS Configuration File for ODI External Authentication

The OPSS configuration file is used to configure the policy, credential, and identity stores, the login modules, and the audit service.

By default, the file that configures OPSS services is named jps-config.xml (for Java EE applications) or jps-config-jse.xml (for Java SE applications).

Configuring the Configuration File for ODI Studio

Configure the configuration file for ODI Studio as follows:

  1. Create a cwallet.sso file (or update it if it already exists) to hide the LDAP server bootstrap credentials namely username and password:

    1. In <ODI_HOME>/oracle.odi.studio/oracledi/client/odi/bin run the odi_credtool.sh script.

      You will be prompted for:

      Parameter Example

      Map name

      Map:jps_map

      Key name

      Key:jps_key

      Bootstrap username

      User name:cn=orcladmin

      Bootstrap password

       

      The Map name and Key name is used to associate with the hidden credentials and will be used in step 4.

    2. The following message will be displayed:

      The credential has been successfully added to the Oracle wallet file: cwallet.sso.
      Please update your jps-config.xml file accordingly on values of the two properties:
      bootstrap.security.principal.map,
      bootstrap.security.principal.key
      
  2. In the same directory, copy the JPS template file jps-config.xml_template to jps-config.xml. This jps-config.xml file will be used by default for your external authentication.

  3. Configure your LDAP server in the jps-config.xml obtained in the previous step with your LDAP server information such as URL, relevant properties and also the bootstrap map and key.

    These LDAP properties are listed in the file in the JPS OID LDAP Identity Store Service Instance configuration section starting with <serviceInstance name="idstore.oid" provider="idstore.ldap.provider">.

    Make sure to match the map and key values given in step 1.1 for the bootstrap.security.principal.map and bootstrap.security.principal.key properties.

    Example 24-1 is an example of the LDAP server configuration in the jps-config.xml file:

    Example 24-1 LDAP Server Configuration in jps-config.xml file

    --------------
    <!-- JPS OID LDAP Identity Store Service Instance -->
    <serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
    <property name="subscriber.name" value="dc=us,dc=oracle,dc=com" />
    <property name="idstore.type" value="OID" />
    
       <property name="bootstrap.security.principal.map" value="jps_map"/>
       <property name="bootstrap.security.principal.key" value="jps_key"/>
    
    
    <property name="ldap.url" value="ldap://example.oracle.com"/><extendedProperty>   <name>user.search.bases</name>   <values>    <value>cn=users,dc=us,dc=oracle,dc=com</value>   </values>  </extendedProperty>  <extendedProperty>   <name>group.search.bases</name>   <values>    <value>cn=groups,dc=us,dc=oracle,dc=com</value>   </values>  </extendedProperty>  <property name="username.attr" value="uid" />  <property name="groupname.attr" value="cn" /> </serviceInstance>
    -----------------
     
    
  4. Launch ODI Studio and create a Master repository with external authentication mode.

Configuring the Configuration File for the Standalone Agent

For the Standalone Agent follow the same procedure as for the configuration for ODI Studio except that the odi_credtool.sh scripto is located in the <ODI_HOME>/oracle.odi.studio/oracledi/agent/bin directory.

24.3.3 Enforcing Password Policies

The Password Policies consist of a set of rules applied on user passwords when using Internal Authentication. This set of rules is applied when the password is defined or modified by the user.

To define the password policy:

  1. From the Security Navigator toolbar menu, select Password Policy...

    The Password Policy dialog appears. This dialog displays a list of rules.

  2. If you want your password to expire automatically, check Password are valid for (days), and set a number of days after which passwords need to be modified.

  3. Click Add a Policy. The Policy Definition dialog appears. A policy is a set of conditions that are checked on passwords.

  4. Set a Name and a Description for this new policy.

  5. In the Rules section, add several conditions on the password text or length. You can define, for example, a minimum length for the passwords.

  6. From the Condition to match list, select whether you want the password to meet at least one or all conditions.

  7. Click OK.

  8. Add as many policies as necessary, and select Active for those of the rules that you want to keep active. Only passwords that meet all the policies are considered as valid for the current policy.

  9. Click OK to update the password policy.

24.3.4 Configuring Single Sign-On (SSO) for Oracle Data Integrator Console and Enterprise Manager using Oracle Access Manager 11g

This section describes how to optionally configure Single Sign-On for Oracle Data Integrator Console and Enterprise Manager with Oracle Access Manager (OAM) 11g.

To configure Single Sign-On for Oracle Data Integrator Console and Enterprise Manager:

  1. Log in to the OAM Console using your browser:

    http://host:port/oamconsole
    
  2. Go to Policy Configuration > Application Domains.

    The Policy Manager pane displays.

  3. Locate the application domain you created using the name while registering webgate agent.

  4. Expand the Resources node and click Create.

    The Resource page displays.

  5. Add the resources that must be secured. For each resource:

    1. Select http as the Resource Type.

    2. Select the Host Identifier created while registering the WebGate agent.

    3. Enter the Resource URL as follows:

      Resource URL ODI Component

      /odiconsole*

      ODI Console

      /odiconsole/.../*

      ODI Console

      /em*

      Enterprise Manager

      /em/.../*

      Enterprise Manager


    4. Enter a Description for the resource and click Apply.

  6. Go to Authentication Policies > Protected Resource Policy and add the newly created resources.

  7. Do the same under Authorization Policies > Protected Resource Policy.

  8. In your WebTier, modify the mod_wl_ohs.conf file (in WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/) to include the ODI Console and Enterprise Manager, by adding two additional Location entries using the actual host ID for the WebCenter Portal Administration Server for WebLogicHost.

    <Location /odiconsole*>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
    <Location /em*>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
    
  9. Restart the Oracle HTTP Server for your changes to take effect.

    You should now be able to access the ODI Console and Enterprise Manager with the following links:

    http://host:OHS port/odiconsole

    http://host:OHS port/em

    and be prompted with the OAM SSO login form.

    For more information about installing and configuring OAM 11g for ODI, see Section 3.4, "Integrating ODI with Oracle Access Mananger 11g" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.