3 Configuring Oracle Enterprise Repository to use External Authentication Tooling

This chapter describes how to authenticate Oracle Enterprise Repository using the external authentication tools.

This chapter contains the following sections:

Section 3.1, "LDAP/Active Directory"
Section 3.2, "eTrust Single Sign-On"
Section 3.3, "Container Managed Setup"

3.1 LDAP/Active Directory

This section describes how to use LDAP/Active Directory to authenticate the users in Oracle Enterprise Repository.

This section contains the following topics:

Section 3.1.1, "Overview"
Section 3.1.2, "Enable LDAP Integration System Properties"
Section 3.1.3, "Modify LDAP/Active Directory Properties"
Section 3.1.4, "Security Considerations"
Section 3.1.5, "LDAP Property Examples"

3.1.1 Overview

When utilizing LDAP / Active Directory (AD) to authenticate users, some consideration must be given to the user's department and role configurations prior to the utilization of LDAP / Active Directory server. All users will be authenticated through LDAP/AD once the integration is enabled; it is essential to have at least one admin-level user account created within the Oracle Enterprise Repository database that matches the username from LDAP/AD. This user account should be assigned the admin role so that administrative functions within Oracle Enterprise Repository can still be performed when LDAP/AD is enabled.

If role synchronization is enabled from LDAP/AD, at least one user account should be assigned an administrative-level role. LDAP roles should be created and appropriate Oracle Enterprise Repository permissions assigned within Oracle Enterprise Repository prior to utilizing the role-synch option. Role names are synchronized on name only. When the administrative-level user logs into Oracle Enterprise Repository using LDAP/AD, that person will have the ability to configure and administer the application properly. This user account should NOT be used for daily activities.

3.1.2 Enable LDAP Integration System Properties

This procedure is performed on the Oracle Enterprise Repository Admin screen.

Click System Settings in the left pane. The System Settings section opens in the main pane.
Locate the Cookie Login Settings group in the Enterprise Authentication section.

Figure 3-1 Cookie Login Settings

Description of "Figure 3-1 Cookie Login Settings"
Ensure that the Allow Cookie Login setting is set to False.
Use the System Settings Search box to easily locate each of the following settings.
Enter enterprise.authentication.ldap.enabled into the Search box. Set the value to True and click Save.

Change the settings as indicated below:
- Default to Cookie Login
  - Set to False.
- Unapproved User Login
  - Set to True.
- Cookie Login Module
  - Set to False.
- Cookie Login Module - Internal Checking
  - Set to False.
- Plug-in Login Module Class Name
  - Enter com.flashline.enterprise.authentication.server.loginmodule.LDAPLogin in the text box.
    
    Note:
    This property turns LDAP on/off. Once enabled, the application will use LDAP server for user authentication.
- Plug-in Login Module Display Name
  - Enter Enterprise LDAP Login in the text box.
- Plug-in Login Module
  - Set to True.
- Plug-in Login Module - Internal Checking
  - Set to False.
Click Save when finished.

3.1.3 Modify LDAP/Active Directory Properties

You can use the Harvester to modify LDAP/AD properties, as follows:

Click System Settings in the left pane.
Use the System Settings Search to easily locate each of the following settings. Enter the values as indicated below:
- LDAP Server Host Name
  - In the text box, enter the Host name, or the directory server IP address.
- LDAP Server Port Number
  - Enter 389 in the text box.
- LDAP Mask
  - Enter uid=^ for LDAP
    
    Or
  - Enter samAccountName=^ for Active Directory
- Creation of Unapproved User Accounts
  - Set to True.
- Assign default roles to users
  - Set to True.
  Note:
  This property will assign default roles on every user authentication.
- Auto create missing roles
  - Set to True.
  Note:
  This property will create roles synchronized from the LDAP/AD server, but will NOT assign any permissions to those roles.
- Auto create missing departments
  - Set to True.
  Note:
  This property will create departments synchronized from the LDAP/AD server, but will not assign any description to those departments. However, the user will be assigned to the new role.
- LDAP Version
  - Enter 3 in the text box. (Supported versions are 2 and 3)
- Administrator Account Distinguished Name
  
  Note:
  This property is required with using Active Directory. This property must contain a DN of a user account with at least read-only directory look-up permissions.
  
  Example: CN=Some_User,CN=Users,DC=ad,DC=example,DC=com
- Administrator Account Password
  - In the text box, enter the password for the administrator account identified in the Administrator Account Distinguished Name property, above.
- Use SSL Connection
  - Set to True to enable an SSL connection for LDAP. The default value is false.
- Follow referrals
  - Set to True.
- Retrieve data using the admin account
  - Set to False for LDAP (if applicable) Or
  - Set to True for Active Directory or restricted LDAP environments.
- Search Start Location
  
  Note:
  This property defines where in the directory tree the search for user records will begin.
  
  Examples:
  - For LDAP: OU=MemberGroupB, O=en_us
  - For Active Directory: CN=Users,DC=ad,DC=example,DC=com
- Search Scope
  - Select subtree in the list.
    
    Note:
    This property defines the depth (below the baseDN) of user record searches.
- Attribute Name that Identifies a Found Entry
  
  Note:
  This property designates the attribute name that uniquely identifies the user account within the scope of the tree search.
  - For LDAP: uid
    
    Or
  - For Active Directory: samAccountName
- Found Entry Email Attribute Name
  - Enter mail
- Found Entry First Name Attribute Name
  - Enter givenName
- Found Entry Middle Name Attribute Name
  - Enter the middle name attribute from your LDAP or Active Directory (if applicable)
- Found Entry Last Name Attribute Name
  - Enter sn
- Found Entry Telephone Number Attribute Name
  - Enter telephoneNumber
- Use LDAP Departments
  - Set to True
    
    Note:
    This property defines the user's department attribute value that will be synchronized within Oracle Enterprise Repository.
- Department Attribute
  - Enter department
- Use LDAP Roles
  - Set to False
- Role Attribute
  - Enter the LDAP / Active directory attribute that contains the role information for the user.
- Second Level Lookup Attribute
  
  Note:
  This property defines the attribute that identifies a second-level lookup to retrieve user info; the value must be a DN. If you are using a redirect for second level lookups, define the base DN for this second lookup.
Click Save when finished.
Restart the Oracle Enterprise Repository application.

3.1.4 Security Considerations

Using the Oracle Enterprise Repository LDAP/Active Directory Connector allows LDAP to act as the single source of user identification for Oracle Enterprise Repository user authentication and role assignment. However, this does not prevent respective host repositories from managing user authentication for access to files through Oracle Enterprise Repository.

When using the Oracle Enterprise Repository LDAP/Active Directory Connector, Oracle Enterprise Repository depends on LDAP or Active Directory to authenticate users. The username/password combination is delegated to the LDAP system as a bind request. The user is authenticated only if the bind request is successful.

As an option, LDAP can be configured to store/retrieve Oracle Enterprise Repository user role assignments. In this configuration, at each user login Oracle Enterprise Repository synchronizes with the user's roles as stored in LDAP. Roles are added directly through LDAP, and are not managed by Oracle Enterprise Repository.

3.1.4.1 Use Case Sample Scenarios

The following scenarios illustrate a selection of LDAP setups and configurations in order to clarify property settings for user management.

Scenario 1

Prevent user access to Oracle Enterprise Repository despite LDAP authentication. Access is provided only to pre-existing users with active Oracle Enterprise Repository accounts.

Rationale
- Non-enterprise license agreements where user base is predefined and number of users allowed into the application is limited.
Property Settings
- ldap.allow-user-creation
  - Set to False
- enterprise.security.unapproveduser.allowlogin
  - Set to False

Scenario 2

On LDAP authentication, create a default Oracle Enterprise Repository user account and assign the default role(s), but deny the user access to the Oracle Enterprise Repository.

Rationale
- To deny Oracle Enterprise Repository access to a new user until the security administrator is notified that the new user account was created. Once approved by the security administrator, the user's status is changed to active, allowing Oracle Enterprise Repository login.
Property Settings
- ldap.allow-user-creation
  - Set to True
- ldap.assign-default-roles
  - Set to True
- enterprise.security.unapproveduser.allowlogin
  - Set to False

Scenario 3

On LDAP authentication, a default Oracle Enterprise Repository user account is created with the default role(s), and the user is permitted to login to the Oracle Enterprise Repository.

Rationale
- An enterprise license agreement in which LDAP authentication is the only restriction on new user creation. Typically, the default Oracle Enterprise Repository role would be set to User in order to limit access for new users whose roles are not predefined by an LDAP account.
Property Settings
- ldap.allow-user-creation
  - Set to True
- ldap.assign-default-roles
  - Set to True
- enterprise.security.unapproveduser.allowlogin
  - Set to True

3.1.5 LDAP Property Examples

Since limitations in Active Directory prevent searches below the top-level of the directory while anonymously bound (not authenticated) to the directory server, Oracle Enterprise Repository user information lookup requires the Bind DN, Bind Password, and Retrieve Data As Admin properties to be set with appropriate values. Table 3-1 describes the LDAP /Active Directoy properties with its examples.

Table 3-1 Active Directory and Traditional LDAP Properties

Active Directory		Traditional LDAP (InetOrgPerson)
ldap.host	ad.example.com	ldap.host	ad.example.com
ldap.port	389	ldap.port	389
ldap.version	3	ldap.version	3
ldap.bindDN	CN=Some_User,OU=Users,DC=ad,DC=example,DC=com	ldap.bindDN	(required if Anonymous lookups are disabled)
ldap.bindPassword	password	ldap.bindPassword	(required if Anonymous lookups are disabled)
ldap.retrieve-data-as-admin	true	ldap.retrieve-data-as-admin	false (TRUE if anonymous lookups are disabled)
ldap.mask	sAMAccountName=^	ldap.mask	uid=^
ldap.baseDN	CN=Users,DC=ad,DC=example,DC=com	ldap.baseDN	OU=MemberGroupB, O=en_us
ldap.scope	subtree	ldap.scope	one
ldap.uniqueIDAttrib	samAccountName	ldap.uniqueIDAttrib	uid
ldap.emailAttrib	mail	ldap.emailAttrib	mail
ldap.givennameAttrib	givenname	ldap.givennameAttrib	givenName
ldap.surnameAttrib	sn	ldap.surnameAttrib	sn
ldap.telephoneAttrib	telephonenumber	ldap.telephoneAttrib	telephoneNumber
ldap.deptAttrib	department	ldap.deptAttrib	department

Table 3-2 describes the custom and common LDAP properties.

Table 3-2 Custom and Common LDAP Properties

Custom and Common Properties Regardless of implementation
ldap.rbac.mapperclass	com.flashline.enterprise.authentication.server.loginmodule.LDAPMapperImpl
ldap.deptAttrib	department
ldap.rbac.roleAttrib	roles
ldap.allow-user-creation	true
ldap.enable-synch-roles	true
ldap.enable-synch-depts	true

3.2 eTrust Single Sign-On

This section describes how to use sTrust Single Sign-On to authenticate the users in Oracle Enterprise Repository.

This section contains the following topics:

Section 3.2.1, "Overview"
Section 3.2.2, "Configure Oracle Enterprise Repository For Use With Single Sign-On Authentication"
Section 3.2.3, "Advanced Options"

3.2.1 Overview

The Oracle Enterprise Repository Advanced Container Authentication LoginModule is used to accept user credentials passed by HTTP Request Headers (potentially populated by an SSO system). This feature allows integration with single-sign-on systems such as eTrust Single Sign-On.

3.2.2 Configure Oracle Enterprise Repository For Use With Single Sign-On Authentication

Access the following configuration properties requires Access Administrator rights.

Note:

This enhancement allows AdvancedContainerLogin Module to accept user information in SOAP Headers for the AuthtokenCreate REX API method. The username is passed in a SOAP Header with a name that is identified by the Oracle Enterprise Repository system setting enterprise.container.auth.username and has a namespaceUri of www.oracle.com/oer. The value of the SOAP Header is the username of the user. If the username is not passed within a SOAP Header then the Oracle Enterprise Repository system setting enterprise.loginmodules.fallbackauthentication is used. If enterprise.loginmodules.fallbackauthentication is true, then the user is authenticated by the configured PluggableLoginModule for the specified username/password.

Plugin in Login module is a configuration set up to configure Database login Module, LDAP Login Module, and Custom Login Module. Container Login module can be Container Managed Login Module or Advanced Container Login Module i.e SSO. These can be configured on the System Settings tab.

This section contains the following topics:

Section 3.2.2.1, "Enable Single Sign-On Integration System Properties"
Section 3.2.2.2, "Using the Oracle Enterprise Repository SSO Integration with Basic Authentication"
Section 3.2.2.3, "Modify Application Property Files Manually"

Note:

The Fallback authentication works only with REX API.

3.2.2.1 Enable Single Sign-On Integration System Properties

This procedure is performed on the Oracle Enterprise Repository Admin screen.

Click System Settings in the left pane. The Oracle Enterprise Repository System Settings screen is displayed, as shown in Figure 3-2.

Figure 3-2 Oracle Enterprise Repository System Settings Screen

Description of "Figure 3-2 Oracle Enterprise Repository System Settings Screen"
Enter enterprise.authentication.advancedcontainer.enabled into the Search box. Set the value to True and click Save.
Enter cmee.jws.pass-all-cookies in the Enable New System Setting text box, as shown in Figure 3-3.

Figure 3-3 Enable New System Settings Dialog

Description of "Figure 3-3 Enable New System Settings Dialog"
Click Enable. JWS Pass All Cookies appears in the Java Web Start (JWS) section of the Server Settings group of system settings, as shown in Figure 3-4.

Figure 3-4 JWS Pass All Cookies

Description of "Figure 3-4 JWS Pass All Cookies"
Make sure the property is set to True.
Click Save.
Enter container login module in the System Settings Search text box. The Containter Login Module section is displayed in the Enterprise Authentication group of system settings, as shown in Figure 3-5.

Figure 3-5 Container Login Settings Section

Description of "Figure 3-5 Container Login Settings Section"
Modify the following properties as indicated:
- Container Login Module Class Name
  - Enter com.flashline.enterprise.authentication.server.loginmodule.AdvancedContainerLogin in the text box.
- Container Login Module Display Name
  - Enter Advanced Container Login Module in the text box.
- Container Login Module
  - Set the property to True.
Supply SSO Header Values as indicated (these are often called Responses within the Policy Server). Data types expected, and possible values are listed below the header name. The expected value types apply to the responses supplied by the policy server:
- Username Header Name
  - Set this property to the Name of the header that will contain the user's UID value.
    
    This header should contain the user's user id (REQUIRED).
- Firstname Header Name
  - Set this property to the Name of the header that will contain the user's First Name value. (Alpha String)
    
    This header should contain the user's proper name.
- Middlename Header Name
  - Set this property to the Name of the header that will contain the user's Middle Name value. (Alpha String)
    
    This header should contain the user's middle name.
- Lastname Header Name
  - Set this property to the Name of the header that will contain the user's Last Name value. (Alpha String)
    
    This header should contain the user's surname.
- Status Header Name
  - Set this property to the Name of the header that will contain the user's Active Status value.
    
    This header should contain a valid integer value specifying the user's status within OER. Refer to the following table for valid values (REQUIRED).
    
    * 00 - Active
    
    * 10 - Unapproved
    
    * 20 - Locked Out
    
    * 30 - Inactive
- Email Header Name
  - Set this property to the Name of the header that will contain the user's Email value.
    
    This header should contain the user's e-mail address (REQUIRED).
- Phone Header Name
  - Set this property to the Name of the header that will contain the user's Phone Number value.
    
    This header should contain the user's phone number.
- Roles Header Name
  - Set this property to the Name of the header that will contain the user's Role(s) value.
    
    This header should contain the user's role(s).
- Department Header Name
  - Set this property to the Name of the header that will contain the user's Department(s) value.
    
    This header should contain the user's department(s).
Update the behavior of the SSO module with the following properties:
- Use Container passed Departments
  - Set this value to True if you would like to synchronize the user's department from the policy server responses.
- Departments passed within single header
  - Set this value to True if more than one department name is passed as a Policy Server response.
- Department Delimiter
  - Set the value of this property to the character that will delimit multiple departments within the single department header. This field can accept Unicode notations such as \u0020 for a space.
- Use Container passed Roles
  - Set this value to True if you would like to synchronize the user's roles from the policy server responses. (NOTE: Setting this value to true prior to verifying the correct configuration may render your Oracle Enterprise Repository application unusable).
- Roles passed within single header
  - Set this value to True if more than one role name is passed as a Policy Server response.
- Role Delimiter
  - Set the value of this property to the character that will delimit multiple roles within the single roles header. This field can accept Unicode notations such as \u0020 for a space.
- Assign default roles to users
  - Set this value to True if existing and new users will be assigned all roles marked as 'default' assigned to their user account within Oracle Enterprise Repository.
- Auto create missing roles
  - Set this value to True to allow Oracle Enterprise Repository to create roles included within a user's role header that do not exist currently within Oracle Enterprise Repository. This feature will create a role and assign the user to that role, but the created role(s) will have no permissions assigned.
- Auto create missing departments
  - Set this value to True to allow Oracle Enterprise Repository to create departments included within a user's department header that do not exist currently. This feature will create a department and assign the user to that department; the newly created department will not be assign to a project.
Enter cookie login module in the System Settings Search text box. The Cookie Login Settings section opens in the Enterprise Authentication group of system settings.
Set the Cookie Login Module property to False.
Enter plug-in login in the System Settings Search text box. The Plugin Login Settings section opens in the Enterprise Authentication group of system settings.
Enter false in the Plug-in Login Module text box.
Click Save.

3.2.2.2 Using the Oracle Enterprise Repository SSO Integration with Basic Authentication

If the Single Sign-On installation uses Basic Authentication, additional property settings are required to allow the Oracle Enterprise Repository Asset Editor to function properly.

Using the process described above, enable the following property:
- cmee.jws.suppress-authorization-header
Set the property to True.
Click Save.

3.2.2.3 Modify Application Property Files Manually

Prerequisite: Stop the application server. Modifications to properties files may impact any applications running on the application server.

Edit the containerauth.properties file in WEB-INF/classes.

This file contains a list of header names that are specific to the Single Sign-On server. This information represents the Response Headers Single Sign-On uses for replies, and should be acquired from your organization's Single Sign-On Administrators/Architects.

If Single Sign-On responses do not provide the appropriate value for an email header, a blank "" can be substituted instead of a true header value. Other fields that are not supplied or populated by Single Sign-On should be left null.

(An asterisk <*> indicates a required field.)
- Configure the Header variables that should be mapped to the appropriate Oracle Enterprise Repository user information:
  
  Note:
  The values indicated below are examples only and must be replaced with the appropriate Single Sign-On Response Header names defined by your Single Sign-On system.
  - enterprise.container.auth.username = <UID>
  - enterprise.container.auth.firstname = <FIRST_NAME>
  - enterprise.container.auth.middlename = <MIDDLE_NAME>
  - enterprise.container.auth.lastname = <LAST_NAME>
  - enterprise.container.auth.status = <STATUS>
  - enterprise.container.auth.email = <MAIL>
  - enterprise.container.auth.phone = <PHONE>
  - enterprise.container.auth.roles = <ROLES>
  - enterprise.container.auth.depts = <DEPARTMENTS>
  - enterprise.container.auth.enable-synch-roles = true
  - enterprise.container.auth.roles-single-header = true
  - enterprise.container.auth.roles-delimiter = \u0020
  - enterprise.container.auth.enable-synch-depts = true
  - enterprise.container.auth.depts-single-header = true
  - enterprise.container.auth.depts-delimiter = \u0020
Note:
The last six properties listed above are utilized when role and/or department synching is enabled, and more than one role or department is supplied in a single header. These additional properties can be disabled/ignored depending on the values supplied in the boolean parameters enable-synch-roles and enable-synch-depts. The delimiter field in this example uses the unicode space character; however, unicode is not required for any other delimeter character.
Most Single Sign-On web agent applications are deployed against an HTTP server that is separate from the Application Server. In this scenario, an AJP type connector (mod_jk/mod_jk2 for Apache HTTP Servers, mod_was_ap20_http for IBM HTTP Server, etc.) will link the HTTP server to the application server. Typically, the HTTP server runs on a seperate machine for performance or resource pooling reasons. In this scenario it is necessary to modify the cmee.properties file to reflect the new name for your application, as outlined below.
- Edit the cmee.properties file in WEB-INF/classes.
  - Original Configuration (Tomcat with Coyote)
    
    - cmee.server.paths.image=http\://tomcat.example.com\:8080/flashline-web/images
    
    - cmee.server.paths.jsp=http\://tomcat.example.com\:8080/flashline
    
    - cmee.server.paths.servlet=http\://tomcat.example.com\:8080/flashline
    
    - cmee.server.paths.jnlp-tool=http\://tomcat.example.com\:8080/flashline-web/webstart
    
    - cmee.server.paths.resource=http\://tomcat.example.com\:8080/flashline-web
    
    - cmee.enterprisetab.homepage=http\://tomcat.example.com\:8080/flashline/custom/home.jsp
    
    - cmee.assettab.asset-detail-page=http\://tomcat.example.com\:8080/flashline/cmee/index.jsp
  - New configuration (Apache HTTP with mod_jk2 to Tomcat)
    
    - cmee.server.paths.image=http\://apache.example.com/flashline-web/images
    
    - cmee.server.paths.jsp=http\://apache.example.com/flashline
    
    - cmee.server.paths.servlet=http\://apache.example.com/flashline
    
    -cmee.server.paths.jnlp-tool=http\://apache.exampe.com/flashline-web/webstart
    
    - cmee.server.paths.resource=http\://apache.example.com/flashline-web
    
    - cmee.enterprisetab.homepage=http\://apache.example.com/flashline/custom/home.jsp
    
    - cmee.assettab.asset-detail-page=http\://apache.example.com/flashline/cmee/index.jsp
  - In this example the new URL to connect to the Repository will be: http://apache.example.com/flashline/index.jsp
Restart the Oracle Enterprise Repository application.

3.2.3 Advanced Options

The following options add functionality for assigning default roles, new user creation/notification, syncing departments, and syncing roles:

Section 3.2.3.1, "Creating/Assigning Default Roles for New Users"
Section 3.2.3.2, "Create New Users/Allow Unapproved Users"
Section 3.2.3.3, "Enable Unapproved/New User Login"
Section 3.2.3.4, "New User Notification"
Section 3.2.3.5, "Syncing Departments"
Section 3.2.3.6, "Syncing Roles"
Section 3.2.3.7, "Enable Debug Logging"

3.2.3.1 Creating/Assigning Default Roles for New Users

With Advanced RBAC:

Click Admin on the Oracle Enterprise Repository menu bar. The Oracle Enterprise Repository Admin screen is displayed.
Click Roles.
Click Create New.
Enter Browse_Only in the name field.
- Check Automatically assign to new users
- Add any existing users who fit this profile.
Click Save.
Click role 1: Create/Submit.
Click Edit.
- Uncheck Automatically assign to new users.
Click Save.
Click the User role.
Click Edit.
- Uncheck Automatically assign to new users. (User is the default role and automatically assigned to new users as shipped with the Oracle Enterprise Repository.)
Click Save.
Click Custom Access Settings.
Click Create New.
Enter Browse_Only in the name field.
- Check Automatically assign to all new assets.
- Locate Browse_Only in the list of roles.
- Check View.
Click Save.
Click OK to apply to all assets.

With Basic Access Settings:

Click Admin on the Oracle Enterprise Repository menu bar. The Oracle Enterprise Repository Admin screen is displayed.
Click Roles.
Click Create New.
Enter Browse_Only in the name field.
- Check Automatically assign to new users
- Add any existing users who fit this profile.
Click the User role.
Click Edit.
- Uncheck Automatically assign to new users. (User is the default role and automatically assigned to new users as shipped with Oracle Enterprise Repository.)
Click Save.

3.2.3.2 Create New Users/Allow Unapproved Users

The Oracle Enterprise Repository Single Sign-On authentication integration will automatically create new users within the Oracle Enterprise Repository database once they are successfully authenticated. The specific access and permissions granted to new users is determined by the configuration of the default New User Role(s), as described in the previous section. Upon approval by the access administrator, new users may be assigned to other roles with different access settings. However, if the Single Sign-On integration is configured with role synchronization enabled, then the user will be assigned the roles provided by Single Sign-On response headers.

3.2.3.3 Enable Unapproved/New User Login

When enabled, this option allows unapproved/new Oracle Enterprise Repository users to access the application after Single Sign-On authentication. If disabled, new or unapproved users cannot access Oracle Enterprise Repository. This feature is particularly useful when a manual approval process is required before accessing the application.

Enable Unapproved User Login = true (file: enterprise.properties)
- enterprise.security.unapproveduser.allowlogin=true

3.2.3.4 New User Notification

When enabled, this property will notify the access adminstrator via email when a new user account is added to Oracle Enterprise Repository via Single Sign-On.

Enable New User Notification = true (file: cmee.properties)
- cmee.new.unapproved.users.notify=true

3.2.3.5 Syncing Departments

When enabled, this property will synchronize department names from Single Sign-On response header values.

Enable Department Syncing = true (file: containerauth.properties)
- enterprise.container.auth.enable-synch-depts - Set to true if known departments are to be synchronized with users, set to false otherwise.
Enable Department Creation = true (file: containerauth.properties)*
- enterprise.container.auth.auto-create-missing-depts - Set to true if user's departments are to be automatically created at login, set to false otherwise.

Notes on Department Synchronization

The Single Sign-On integration will not create new departments. It will only link users to departments that already exist within Oracle Enterprise Repository and have the same name as that provided in the Single Sign-On response header value(s).

The Single Sign-On server may be configured to pass multiple headers of the same name but different values for each department a user is assigned, or one header containing all of the departments that a user is assigned.

Configuration 1 - A multiple headers of the same name, with a different value in each:

enterprise.container.auth.enable-synch-depts= true

enterprise.container.auth.depts-single-header= false

enterprise.container.auth.depts-delimiter= ""

enterprise.container.auth.depts= DEPT_HEADER_NAME

DEPT_HEADER_NAME=DEPTA

DEPT_HEADER_NAME=DEPTB

DEPT_HEADER_NAME=DEPTC

and NOT

DEPT_HEADER_NAME=DEPTA DEPTB DEPTC ..
Configuration 2 - One header with multiple values seperated by a delimeter:

enterprise.container.auth.enable-synch-depts= true

enterprise.container.auth.depts-single-header= true

enterprise.container.auth.depts-delimiter= "^"

enterprise.container.auth.depts= DEPT_HEADER_NAME

DEPT_HEADER_NAME=DEPTA^DEPTB^DEPTC^ ...

and NOT

DEPT_HEADER_NAME=DEPTA

DEPT_HEADER_NAME=DEPTB

DEPT_HEADER_NAME=DEPTC

3.2.3.6 Syncing Roles

When enabled, this property will synchronize role names from Single Sign-On response header values.

Enable Role Syncing = true (file: containerauth.properties)
- enterprise.container.auth.auto-create-missing-roles - Set to true if unknown roles are to be auto-created, set it to false otherwise.

Notes on Role Synchronization

The Single Sign-On integration can create new roles. The integration will link users to roles that previously exist within the Oracle Enterprise Repository and have the same name as that provided in the Single Sign-On response header value(s). In addition to linking to existing roles, the integration will also create roles found in the header values that do not already exist within the Oracle Enterprise Repository. Roles created in this way will have no rights assigned to them by default.

Enable Missing Role Creation = true (file: containerauth.properties)
- enterprise.container.auth.auto-create-missing-roles = true

The Single Sign-On server may be configured to pass one header value for each role a user is assigned.

Configuration 1 - A multiple headers of the same name, with a different value in each:

enterprise.container.auth.enable-synch-roles= true

enterprise.container.auth.roles-single-header= false

enterprise.container.auth.roles-delimiter= ""

enterprise.container.auth.roles= ROLE_HEADER_NAME

ROLE_HEADER_NAME=ROLEA

ROLE_HEADER_NAME=ROLEB

ROLE_HEADER_NAME=ROLEC

and NOT

DEPT_HEADER_NAME=ROLEA ROLEB ROLEC ...
Configuration 2 - One header with multiple values seperated by a delimeter:

enterprise.container.auth.enable-synch-roles= true

enterprise.container.auth.roles-single-header= true

enterprise.container.auth.roles-delimiter= "^"

enterprise.container.auth.roles= ROLE_HEADER_NAME

DEPT_HEADER_NAME=ROLEA^ROLEB^ROLEC^ ...

and NOT

ROLE_HEADER_NAME=ROLEA

ROLE_HEADER_NAME=ROLEB

ROLE_HEADER_NAME=ROLEC

3.2.3.7 Enable Debug Logging

Enable debug logging by appending the following line in the log4fl.properties file:

log4j.category.com.flashline.enterprise.authentication.client.LoginContext=debug, cmeeLog

3.2.3.8 Known Issues

This section contains the known issues with eTrust Single Sign-On.

3.3 Container Managed Setup

This section describes how to use Container Managed setup to authenticate the users in Oracle Enterprise Repository.

This section contains the following topics:

Section 3.3.1, "Overview"
Section 3.3.2, "Configure the Container to Support Realm Authentication"
Section 3.3.3, "Configure Oracle Enterprise Repository for Container Managed Authentication"
Section 3.3.4, "Modify the Web Application's Web.xml File to Allow for Container Authentication"

3.3.1 Overview

The container is configured appropriately with a Realm or Authenticator back-end prior to enabling the values within the Oracle Enterprise Repository application.

3.3.2 Configure the Container to Support Realm Authentication

Please refer to your application server configuration documentation to define a security realm. A sample realm configuration for Tomcat is mentioned below:

An example realm configuration for Tomcat 5.5.x is mentioned below. This realm definition is included within the $CATALINA_HOME/conf/server.xml file.

Note:

Only one realm can be active within the $CATALINA_HOME/conf/server.xml file at a time.

<Realm className="org.apache.catalina.realm.JNDIRealm"
         debug="99"
         connectionURL="ldap://ldap1.example.com:389"
         alternateURL="ldap://ldap2.example.com:636"
         contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
         authentication="simple"
         referrals="follow"
         userBase="OU=people,DC=example,DC=com"
         userSubtree="true"
         userSearch="(uid={0})"
         userRoleName="employeeType"
         roleBase="ou=groups,DC=example,DC=com"
         roleName="cn"
         roleSearch="(uniqueMember={0})"
         roleSubtree="true"/>

If you would want to use the UserDatabaseRealm defined within Tomcat, which is enabled by default, then you can set the contents of your CATALINA_HOME/conf/tomcat-users.xml file as follows:

<?xml version='1.0' encoding='utf-8'?>
   <tomcat-users>
       <role rolename="user"/>
       <role rolename="systemAdministrator"/>
       <role rolename="bogus"/>
       <role rolename="aler_user"/>
       <role rolename="admin"/>
       <user username="user" password="user" roles="aler_user,user"/> <!--
 Positive Test case -->
       <user username="u1" password="u1" roles="user"/> <!-- Negative Test Case
 -->
       <user username="container" password="container" roles="aler_user,user"/>
       <user username="bogus" password="bogus" roles="bogus"/>
       <user username="admin" password="admincontainer" roles="aler
_user,user,admin"/>
   </tomcat-users>

3.3.3 Configure Oracle Enterprise Repository for Container Managed Authentication

You can configure the Oracle Enterprise Repository for container managed authentication with the Access Administrator rights. This procedure is performed on the Oracle Enterprise Repository Admin screen.

Enter container login module in the System Settings Search text box. The Containter Login Module section is displayed in the Enterprise Authentication group of system settings, as shown in Figure 3-5.
Modify the following properties as indicated:
- Container Login Module Class Name
  - Enter com.flashline.enterprise.authentication.server.loginmodule.ContainerLogin in the text box.
- Container Login Module Display Name
  - Enter Container Login Module in the text box.
- Container Login Module
  - Set the property to True.
- Enable the Container Managed Authentication Feature
  - Set the enterprise.authentication.container.enabled to True.
- Enable Role Synchronization from the User's Security Principle
  - Set the enterprise.authentication.container.synchroles.enabled to True.
    
    Note:
    When using Container Managed Authentication with BPM Harvester, the Exchange Utility, or any other REX operation, this property must be set to false. With this property set to false, user accounts will need to be created manually and have roles assigned to them by someone with at least accessAdministrator-level permissions.
Click Save.
Enter cookie login module in the System Settings Search text box. The Cookie Login Settings section opens in the Enterprise Authentication group of system settings.
Set the Cookie Login Module property to False.
Click Save.
Enter plug-in login in the System Settings Search text box. The Plugin Login Settings section opens in the Enterprise Authentication group of system settings.
Enter false in the Plug-in Login Module text box.
Click Save.

3.3.4 Modify the Web Application's Web.xml File to Allow for Container Authentication

Stop the Oracle Enterprise Repository application or the application server that it runs within.

Modify the Oracle Enterprise Repository web.xml file:

Add the following security constraint contents to the end of the file.

Note:

This configuration will need to be modified to fit your authentication requirements. This example uses BASIC authentication, which may not be appropriate for your environment.

<!-- Define a security constraint on this application -->
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Entire Application</web-resource-name>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>PUT</http-method>
    <http-method>POST</http-method>
    <http-method>DELETE</http-method>
  </web-resource-collection>
  <auth-constraint>
    <description>These roles have access to the Oracle Enterprise
 Repository</description>
    <role-name>user</role-name>
  </auth-constraint>
</security-constraint>
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Secure Web Service</web-resource-name>
    <url-pattern>/services/FlashlineRegistry</url-pattern>
  </web-resource-collection>
</security-constraint>
<!-- Define the login configuration for this application -->
<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>Oracle Enterprise Repository</realm-name>
</login-config>
<security-role>
   <role-name>user</role-name>
   <role-name>admin</role-name>
   <role-name>accessAdministrator</role-name>
   <role-name>advancedSubmitter</role-name>
   <role-name>businessAnalyst</role-name>
   <role-name>projectAdministrator</role-name>
   <role-name>projectArchitect</role-name>
   <role-name>registrar</role-name>
   <role-name>registrarAdministrator</role-name>
   <role-name>systemAdministrator</role-name>
</security-role>

Start / Restart the Oracle Enterprise Repository application.