This is the admin user who can log into RASADM. The RASADM run-time user is a Real Application Security user with password, who can directly logon to the database. The user must have a Real Application Security role granted (RASADM_POLICY_ADMIN or RASADM_USER_ADMIN or both roles) in order to access RASADM.

RAS provides two administrative roles - RASADM_POLICY_ADMIN and RASADM_USER_ADMIN.

The RASADM_POLICY_ADMIN is a Real Application Security role, which has the privileges to perform Policy Administration; for example, a Real Application Security user with this role can create policies, privileges, privilege classes, namespaces, and regular and dynamic roles. The user cannot create Real Application Security users.

The RASADM_USER_ADMIN is a Real Application Security role, which has the privileges to perform User Management; for example, a Real Application Security user with this role can create users, and regular and dynamic roles. The user cannot use the rest of the features provided by RASADM.

However, both roles have the privileges to view reports on all pages.

The RASADM user can be created using Real Application Security Admin API (in PL/SQL) at the database.

The RASADM expects two kinds of users. One who can perform only Policy Administration tasks and the other who can perform both Policy and User Administration. The former needs to be granted with RASADM_POLICY_ADMIN Real Application Security role and the latter needs to be granted both RASADM_POLICY_ADMIN and RASADM_USER_ADMIN Real Application Security roles.

Application Express and workspace configuration is the configuration that should be done at the Application Express instance level by the Application Express administrator or at the workspace level by the workspace administrator.

This configuration involves performing SSL setup. Oracle strongly recommends that SSL be used:

• Between the browser and the HTTP server

  See the topics about utilizing secure sockets Layer (SSL) in Oracle Application Express App Builder User’s Guide and requiring HTTPS in Oracle Application Express App Builder User’s Guide.

  See the HTTP Server documentation for more information about setting up SSL.

• Between the HTTP server to the database

  See the topics about configuring wallet information in Oracle Application Express Administration Guide and enabling the HTTP Listener to use SSL in Oracle XML DB Developer’s Guide. See the topic about configuring secure sockets layer authentication in Oracle Database Security Guide.

• Between the database to LDAP

  See the topics about configuring secure sockets layer (SSL) in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory, configuring SSL by using LDAP commands in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory, and setting up LDAP directory verification in Oracle Application Express App Builder User’s Guide.

Shows how many application users and role entities are created from external stores and in the database.

Click the Count link to view an entity's summary report.

Shows how many data security entities are created, including data security policies, data realms, and privilege classes.

Click the Count link to view an entity's summary report.

Shows how many modifications there are for each entity for each time period.

Shows for each policy, when it was modified and created, its name and description, target object, and current status.

Click Next to view the next set of records.

Shows for each data realm, when it was modified and created, the policy name, the data realm name to which the ACL was granted, and the ACL that was granted to the data realm.

Click Next to view the next set of records.

Shows for each principal type, role or dynamic role, when it was modified and created, the role name, description, and type.

Click Next to view the next set of records.

Shows for each user, when it was modified and created, the user name, description, and status.

Click Next to view the next set of records.

Shows the name of the audit policy and other important information.

Shows the condition associated with the audit policy, the auditing option defined in the audit policy, the evaluation option (STATEMENT, SESSION, or INSTANCE) associated with the audit policy's condition, and whether the audit policy is a common audit policy (YES) or local (NO) or NULL in non-CDBs. Click Next to view the next set of records.

Shows the database user name for whom the policy is enabled and other important information.

Shows if the audit policy is enabled for all users the value is ALL USERS; name of the audit policy; the enabled option (BY, EXCEPT, or DISABLED) of the audit policy; indicates whether the audit policy is enabled for auditing successful events (YES) or not (NO); and indicates whether the audit policy is enabled for auditing unsuccessful events (YES) or not (NO). Click Next to view the next set of records.

From the Users tab, create each application user you need to add to your data security policy for this application.

To create an application user:

1. Click the Users tab.

   Note:

   Steps 2 to 5 are not applicable for the user without RASADM_USER_ADMIN Real Application Security role.

2. On the Users page, click Create.

   Note:

   The Create button would be invisible for a user without RASADM_USER_ADMIN Real Application Security role.

3. On the Manage User page in the Application User section, enter information in the following fields. A red asterisk denotes a required field.

   • User Name - Enter the name of the application user. Names are case sensitive.

   • Description - Enter a brief description about this application user.

   • Default Schema - Click ( ^) to select the schema for this application user to access.

   • Roles Default Enabled - Choose whether the default application roles are enabled (Yes) or not (No).

   • Status - Choose whether the application user is to be active or inactive.

   • Start Date - Click the calendar icon to select an effective start date for this application user or leave the field blank. No start date means this application user is always effective.

   • End Date - Click the calendar icon to select an effective end date for this application user or leave the field blank. No end date means this application user is always effective. If you specify a start date, you must specify an end date.

   In the Roles Grants section, select application roles to be granted to the application user. An application role must already have been created to select it. A red asterisk denotes a required field. Enter information in the following fields:

   • Role - Click ( ^) to select an application role to be granted to this application user.

   • Start Date - Click the calendar icon to select an effective start date for this role grant or leave the field blank. No start date means this role grant is always effective.

   • End Date - Click the calendar icon to select an effective end date for this role grant or leave the field blank. No end date means this role grant is always effective. If you specify a start date, you must specify an end date.

   Click Add to grant the role.

   To grant more application roles to this application user, choose another role, and if needed select the start date and end date, and then click Add, and so forth.

   To delete one or more application roles from this user, select each one and then click Delete.

4. Click Apply Changes to create this application user.

5. Repeat Steps 1 through 4 for each application user you need to add to your data security policy for this application.

From the Users tab, make updates to application users in your application. The RASADM user can grant more application roles to or delete some application roles from the application user.

To update information for an application user:

1. Click the Users tab.

2. Select the name of the application user in the User column you want to update.

3. On the Manage User page, make your updates.

   To grant more application roles to the application user, choose another role, and if needed enter the start date and end date, and then click Add.

   To delete one or more application roles from an application user, select each one to be deleted in the Direct Role Grants section, and then click Delete.

   If an application user has indirectly been granted one or more application roles, these application roles are listed in the Indirect Role Grants section along with the name of the root role and the grant path.

   Note:

   All the buttons except Cancel will be invisible to a user without RASADM_USER_ADMIN Real Application Security role.

4. Click Apply Changes to save your changes.

From the Users tab, delete any application users that are no longer needed for this application.

To delete an application user:

1. Click the Users tab.

2. In the User column of the Users page, click the name of the application user you want to delete.

3. In the Application User section of the Manage User page, click Delete.

Create the application roles and dynamic roles you need for the data security policy for this application.

To create an application role:

1. Click the Roles tab.

2. On the Roles page, click Create Role.

3. On the Manage Role page in the Application Role section, enter information in the following fields. A red asterisk denotes a required field.

   • Role Name - Enter the name of the application role. Names are case sensitive.

   • Description - Enter a brief description for this application role.

   • Role Type - Choose REGULAR or DYNAMIC. Role Type: Regular = application role, Dynamic = dynamic application role.

     • REGULAR

       Enabled by Default - Choose whether to enable this application role upon creation (Yes) or not to enable it (No) (the default) upon creation.

       Start Date - Click the calendar icon to select an effective start date for this application role or leave the field blank. No start date means this application role is always effective.

       End Date - Click the calendar icon to select an effective end date for this application role or leave the field blank. No end date means this application role is always effective. If you specify a start date, you must specify an end date.

     • DYNAMIC

       Duration - Enter the duration (in minutes) of the dynamic application role.

       Scope - Enter the scope attribute of the dynamic application role. Session, the default, means the enabled dynamic application role is still enabled when you detach the session and attach to the session again, unless you explicitly specify that it be disabled in the session reattach. Request means that the dynamic application role is disabled after the session is detached.

   In the Role Grants section, select application roles to be granted to the application role. A role must already have been created to grant it. A red asterisk denotes a required field. Enter information in the following fields:

   • Role - Click ( ^) to select an application role to be granted to this application role.

   • Start Date - Click the calendar icon to select an effective start date for this role grant or leave the field blank. No start date means this role grant is always effective.

   • End Date - Click the calendar icon to select an effective end date for this role grant or leave the field blank. No end date means this role grant is always effective. If you specify a start date, you must specify an end date.

   Click Add to grant the role.

   To grant more application roles to this application role, choose another application role, and if needed select the start date and end date, and then click Add, and so forth.

   To delete one or more granted application roles from this application role, select each role to be deleted and click Delete.

4. Click Apply Changes to create the application role.

5. Repeat Steps 1 through 4 for each application role you need to add to your data security policy for this application.

From the Roles tab, grant more application roles to an application role or delete one or more application roles from an application role. Check the Indirect Role Grants section if an application role has indirectly been granted one or more application roles.

To update information for an application role:

1. Click the Roles tab.

2. In the Role column of the Roles page, select the name of the application role you want to update.

3. On the Manage Role page, make your updates.

   To grant more application roles to the application role, choose another application role, and if needed select the start date and end date, and then click Add.

   To delete one or more granted application roles from an application role, select each one to be deleted in the Role Grants section, and then click Delete.

   If an application role has indirectly been granted one or more application roles, these application roles are listed in the Indirect Role Grants section along with the name of the root role and the grant path.

4. Click Apply Changes to save your changes.

From the Roles tab, delete the roles that you no longer need in your data security policy for this application.

To delete an application role:

1. Click the Roles tab.

2. In the Role column of the Roles page, click the name of the application role you want to delete.

3. In the Application Role section of the Manage Role page, click Delete.

From the Privileges tab, create each application privilege class you need to add to your data security policy for this application.

To create application privilege classes:

1. Click the Privileges tab.

2. On the Privileges page, click Create.

3. On the Manage Privilege page in the Privilege Class section, enter information in the following fields. A red asterisk denotes a required field.

   • Privilege Class Schema - Click ( ^) to select the schema name.

   • Privilege Class Name - Enter a name for the privilege class. Names are case sensitive.

   • Description - Enter a brief description for the privilege class.

   In the Application Privileges section, enter information in the following fields. A red asterisk denotes a required field.

   • Privilege Name - Enter the name of the privilege.

   • Description - Enter a brief description for this privilege.

   • Implied Privileges - Select one or more DML privileges listed to be implied privileges. When the application privilege is granted to a principal, its implied privileges are also granted.

   Click Add to add the application privilege to this application privilege class.

   Repeat this step to add additional application privileges to this application privilege class.

4. Click Apply Changes to create the application privilege class.

5. Repeat Steps 1 through 4 for each privilege class you need to add to your data security policy for this application.

From the Privileges tab, add new application privileges to the application privilege class or delete one or more application privileges from the application privilege class.

To update information for an application privilege class:

1. Click the Privileges tab.

2. In the Privilege Class column of the Privileges page, select the name of the privilege class you want to update.

3. On the Manage Privilege page, make your updates.

   To add a new application privilege to this privilege class, enter the privilege name, a brief description of the privilege, select the DML privileges to be implied privileges for this application privilege, and then click Add.

   To delete one or more application privileges from the privilege class, select each one to be deleted in the Application Privileges section, and then click Delete.

4. Click Apply Changes to save your changes.

From the Privileges tab, delete the application privilege class from your data security policy for this application.

To delete an application privilege class:

1. Click the Privileges tab.

2. In the Privilege Class column of the Privileges page, click the name of the privilege class you want to delete.

3. In the Privilege Class section of the Manage Privilege page, click Delete, and then click OK to delete the privilege class.

From the Policies tab, create the data security policy to secure data rows and columns for tables or views for this application.

To create a data security policy:

1. Click the Policies tab.

2. On the Policies page, click Create.

3. Policy Information. Enter information in the following fields. A red asterisk denotes a required field.

   • Policy Owner - Click ( ^) to select a policy owner.

   • Policy Name - Enter a name for the data security policy. Names are case sensitive.

   • Description - Enter a brief description for the data security policy.

   • Privilege Class - Click ( ^) to select a privilege class. Or click NEW to create a new privilege class, or click MODIFY to update the selected privilege class.

   • Protected Object's Schema - Click ( ^) to select the name of the object's schema to be protected.

     Note:

     Only the authorized schemas are shown in the list of values. You must grant the SELECT privilege on the target object if a specific schema is not shown.

   • Protected Object - Click ( ^) to select the object to be protected.

   Click Next to continue after entering information in the Policy Information section.

4. Column Authorization. Enter the following information to create a column authorization:

   • Column - Click ( ^) to select the name of the column to be protected.

   • Privilege - Click ( ^) to select a privilege to be applied to the column. The privilege must already have been created. The list of privileges that appear are those associated with the Privilege Class you selected on the Policy Information page in Step 3.

   Click Add to add the column authorization to the Column Authorization Created list. Repeat this step to add additional column authorizations.

   Click Next to continue after entering information in the Column Authorization section.

5. Data Realm Authorization. Enter information in the following fields:

   • Name - Enter the name of the data realm. Names are case sensitive.

   • Description - Enter a brief description about this data realm.

   • Realm Type - Select the type of data realm:

     • REGULAR - Allows you to create a data realm or set of data associated with an ACL, in which the data set is defined by a SQL predicate and the authorization is defined in the ACL. The ACL specifies what privileges are granted to which principals on the data set. For a REGULAR data realm, specify the SQL predicate and an ACL.

       For example, if you want to create a data realm for the DEPARTMENT table with the ID of 60 in the HR schema, you would specify a SQL predicate of DEPARTMENT_ID=60. The defined ACL would grant the SELECT privilege to the principal EMPLOYEE for the principal store DATABASE and also grant the VIEW_SALARY privilege to the principal EMPLOYEE for the principal store DATABASE. This would allow only the employees for this department with the ID of 60 to view their own salary.

       ACL

       Enter the following information:

       ACL Name - Click ( ^) to select an ACL name. Or, click NEW to create an ACL. Or select an ACL name and click MODIFY to modify the ACL.

     • INHERITED - Also known as master-detail, allows you to use the master object's policy to protect the detail object by pointing to a master object, so you do not have to create another duplicate policy on the detail object. For an INHERITED data realm, you must choose the Parent Schema and Parent Object and optionally enter a When Condition. The When Condition is used to further filter the child table records that could meet the parent to child relationship. The parent to child relationship is defined by giving parent.column = child.column.

       For example, using the HR schema, if you want to create a master-detail policy between the DEPARTMENTS parent table and the EMPLOYEES child table, you would specify HR as the Parent Schema, DEPARTMENTS as the Parent Object and enter 1=1 for the When Condition. Then, for Realm Inheritance, you would select DEPARTMENT_ID(NUMBER) as the Parent Column, select COLUMN NAME as the Child Type, then select DEPARTMENT_ID(NUMBER) as the value, then click Add. The Realm Inheritance list will show the entry: (HR.DEPARTMENTS) DEPARTMENT_ID= (HR.EMPLOYEES) DEPARTMENT_ID, which establishes the parent = child pair join condition to form the 1:1 relationship.

       Enter information for the following fields:

       Parent Schema - Select the name of the parent schema as the master object.

       Parent Object - Select the name of the parent object as the master object.

       When Condition - Enter a predicate to further filter the child records that you want to be protected by the parent's object policy or use Predicate Builder to create the predicate.

       Realm Inheritance

       Enter information for the following fields:

       Parent Column - Select the parent column.

       Child Type - Select the child type. If COLUMN NAME is selected, click ( ^) in the adjacent field to choose the column name. If VALUE is selected, enter a value in the field to the right.

       Click Add to add this realm inheritance to the list.

       Repeat this process to add more realm inheritances to the Realm Inheritance list.

       Realm Inheritance - Lists the realm inheritance relationships already created.

       Data Realm Created - Lists the created data realms.

     • PARAMETERIZED - Allows parameters to be used in the realm's SQL predicate, such as department=&DEPT_ID. Note the use of the symbol & preceding the parameter name to represent the parameter. With a parameterized data realm, multiple "value-ACL" can be given to one parameter, which in turn, allows that parameterized data realm to be instantiated as multiple regular data realms, so you do not have to create multiple regular data realms. For a PARAMETERIZED data realm, you must specify the SQL predicate and an ACL.

       For example, if you specify DEPARTMENT_ID=&DEPT_ID,. the parameter name DEPT_ID is associated with different department IDs, which are each granted permission. This enables you to create the grant based on department IDs without having to create many department ID-specific data realms for each DEPT_ID value.

       ACL Parameters

       Enter information for the following fields:

       ACL - Click ( ^) to select an ACL name. Or, click NEW to create an ACL, or click MODIFY to update the selected ACL.

       Parameter Name - Enter a parameter name or click ( ^) to select a parameter name from the list. The parameter name is automatically extracted from the predicate and appears in this list.

       Parameter Type - Select the parameter type: NUMBER or VARCHAR.

       Parameter Value - Enter the parameter value.

       Click Add to add this ACL parameter to the list.

       Repeat this process to add more ACL parameters to the ACL Parameters list.

       ACL Parameters - Lists the ACL parameters that are already defined.

   • SQL Predicate - Click ( ^) to select a SQL predicate. Or, click (>) to expand the Predicate Builder field and enter information for the following fields:

     • Column Name - Click ( ^) to select a column name. The list of columns from which to select are those associated with the Protected Object you selected on the Policy Information page in Step 3.

     • Operator - Click ( ^) to select an operator.

     • Value - Enter a value. The value field will auto-complete to automatically populate values for selection that match the value entered. For the parameterized data realm, once & is entered, the previously defined parameters are automatically populated from which you select the one you want.

     • AND/OR - If needed, click (v) and select AND or OR to further develop the SQL predicate.

     • Predicate Construction - As you construct the SQL Predicate, it will be constructed in this field and provide you feedback as to whether the predicate is valid and complete to assist you in this operation.

     Click Preview to test the SQL predicate. Inspect the query results that display. If the results are satisfactory, click Apply to add the predicate to the SQL Predicate field.

     Click Next to add the data realm to the Data Realm Authorization list.

     Repeat this process to create additional data realms and to add them to the Data Realm Created list.

     In the Data Realm Created list, click ( ^) or click (v) to reorder the evaluation order for each data realm. The first data realm in the list is evaluated first, the second one is evaluated next, and so on.

     To delete one or more data realms from the Data Realm Grant list, select them, and click Delete.

   ACL

   To create an ACL, on the Access Control List (ACL) section, enter information for the following fields:

   • ACL Name - Enter the name of the ACL. Names are case sensitive.

   • Description - Enter a brief description for the ACL.

   • ACL Inheritance - Click (>) to expand the field. Enter the following information:

     • Parent - Click ( ^) to select a parent ACL.

     • Inherit Mode - Choose Extended or Constrained.

       Extended means extending ACL inheritance (OR with ordered evaluation). This option dictates that the ACEs are evaluated from the bottom of the inheritance tree to its top, from child to parent.

       Constrained means constraining ACL inheritance (AND) requires that both the child and the parent ACL grant the application privilege so that the ACL check evaluates to true.

     For Privilege Grants, enter the following information:

     • Principal - Click (<-) to specify search criteria to find the principal, then select the principal. For search criteria, specify the Principal Type as Role or User, and Principal Store as Database or External, and then click Search. Select the principal from the return list. Note that the word Database mentioned here means the principal store for the Real Application Security application user and role.

     • All Except - Select this option to grant all privileges to the principal except the one specified or leave this option deselected to grant or deny only the specified privilege.

     • Privilege - Click (v) to select the application privilege.

     • Grant Type - Choose Grant to grant this application privilege to this principal or choose Deny to deny this application privilege from this principal.

     • Start Date - Click the calendar icon to select an effective start date for this privilege grant or leave the field blank. No start date means this privilege grant is always effective.

     • End Date - Click the calendar icon to select an effective end date for this privilege grant or leave the field blank. No end date means this privilege grant is always effective. If you specify a start date, you must specify an end date.

     Click Add to add this privilege grant to the ACL.

     Repeat this process to add another privilege grant to the ACL.

     In the Privilege Grants list, click ( ^) or click (v) to reorder the evaluation order for each privilege grant. The first privilege grant in the list is evaluated first, the second one is evaluated next, and so on.

     To delete one or more privilege grants from an ACL, select them and then click Delete.

   Click Apply Changes to create the ACL.

   Note:

   At this point, if you click Cancel to cancel creating the data security policy, the ACL you just created is not associated with a data security policy. This ACL can be viewed in the ACL list during security policy creation and reused only if the next data security policy you create has the same security class. Otherwise, not using the same security class, this ACL is not listed in the ACL list and reused.

   Click Add to add this data realm to the Data Realm Created list.

   Click Next to continue after entering information in the Data Realm Authorization section.

6. Apply Policy. The Policy Name and Object Name names display for the data security policy. Enter the following information:

   • In the Apply Policy field, specify the policy status for this policy as either Apply, Remove, Enable, or Disable. If you select Apply, specify the Apply Options.

   • Click (>) to expand Apply Options. Enter information for the following fields:

     • ACL Per Row - Whether the policy is to create hidden columns. True or False, the default is False. A value of True creates the hidden columns SYS_ACLOD.

     • Owner Bypass - Whether the owner of the row can bypass the data security policy, True or False, the default is False.

     • Statement Type - Whether to enforce all statement types (Select, Insert, Update, Delete) for this policy. Deselect statement types as needed; by default all statement types are selected.

   Click Apply Changes to create the data security policy.

From the Policies tab, update the data security policy by applying the same policy to other objects, such as a table or view to secure these data rows and columns for this application.

To update information for a data security policy:

1. Click the Policies tab.

2. In the Policy column of the Policies page, select the policy name you want to update.

3. On the Policy Definition page, make your updates.

   Note that an update you can make is to apply the same policy to other objects, such as a table or view. You can do that by clicking ADD next to the Protected Objects field on the Policy Definition page. After selecting the object to protect and clicking Apply Changes, the Apply Policy page displays where you can click Apply Changes to apply the policy on the new object. During the apply operation, a validation is performed to validate the column or realm authorization applicable to the new object. If the column authorization is not valid for this new object, RASADM does not allow you to complete the apply operation. If the realm predicate is not valid, a warning displays next to the object's name, but RASADM allows you to apply the policy.

4. Click Apply Changes to save your changes.

From the Policies tab, delete the data security policy for the table or view that is no longer needed for this application.

To delete a data security policy:

1. Click the Policies tab.

2. In the Policy column of the Policies page, click the policy name you want to delete.

3. In the Policy section of the Policy Definition page, click Delete, and then click OK to delete the policy.

From the Namespaces tab, create the session namespace you need to add to your data security policy for this application.

To create a namespace:

1. Click the Namespaces tab.

2. On the Namespaces page, click Create.

3. On the Manage Namespaces page in the Application Namespace section, enter information in the following fields. A red asterisk denotes a required field.

   • Namespace Name - Enter a name for the namespace. Names are case sensitive.

   • Description - Enter a brief description for the namespace.

   • ACL - Click ( ^) to select an ACL for this namespace.

     Or click NEW to create an ACL or MODIFY to update the selected ACL, and on the Access Control List (ACL) page, enter or change the following information.

     • ACL Name - Enter the name of the ACL. Cannot change this name.

     • Description - Enter a brief description for the ACL.

     For ACL Inheritance, click (>). Enter the following information:

     • Parent - Click ( ^) to select a parent ACL.

     • Inherit Mode - Choose Extended or Constrained.

       Extended means Extending ACL inheritance (OR with ordered evaluation). This option dictates that the ACEs are evaluated from the bottom of the inheritance tree to its top, from child to parent.

       Constrained means constraining ACL inheritance (AND) requires that both the child and the parent ACL grant the application privilege so that the ACL check evaluates to true.

     For Privilege Grants, enter the following information:

     • Principal - Click (<-) to select a principal. Select the Principal Type: Role or User, Principal Store: Database or External, and optionally enter filter information in the Principal Filter field, then click Search. From the search results shown, click Select to choose the desired Principal name.

       Database means the database store is to be used. Note that the word Database mentioned here means the principal store for the Real Application Security application user and role.

       For External, optionally enter filter information in the Principal Filter field, select the ReFetch option and then in the Principal Store Password field, enter the password, then click Search. From the results shown, click Select to choose the desired Principal name.

     • All Except - Select this option to grant all privileges to the principal except the one specified or leave this option deselected to grant or deny only the specified privilege.

     • Privilege - Click (v) to select an application privilege.

     • Grant Type - Choose Grant to grant this application privilege to this principal or choose Deny to deny this application privilege from this principal.

     • Start Date - Click the calendar icon to select an effective start date for this privilege grant or leave the field blank. No start date means this privilege grant is always effective.

     • End Date - Click the calendar icon to select an effective end date for this privilege grant or leave the field blank. No end date means this privilege grant is always effective. If you specify a start date, you must specify an end date.

     Click Add to add the privilege grant to the ACL.

     Repeat this process to create another privilege grant to add to the ACL.

     In the Privilege Grants list, click ( ^) or click (v) to reorder the evaluation order for each privilege grant. The first privilege grant in the list is evaluated first, the second one is evaluated next, and so on.

     To delete one or more privilege grants from an ACL, select them, and then click Delete.

   • Event Handler - Indicate whether an event handler is needed, No or Yes. If you indicate Yes, click (^) to select the Handler Schema, Handler Package, and Handler Function.

   In the Application Attributes section, you can add namespace attributes and their default values. Enter information in the following field.

   • Attribute and Default Value - Click Add to add a namespace attribute and its default value. Enter the attribute name in the Attribute column and its default value in the Default Value column. Select the Attribute Event: None, First Read, Modify, or First Read and Modify. Then click Add to add this application attribute.

   Click Add to add another namespace attribute name and its default value.

4. Click Apply Changes to create the namespace.

5. Repeat Steps 1 through 4 for each namespace you need to add to your data security policy for this application.

From the Namespaces tab, make updates to any existing namespace by either adding an event handler if it did not have one previously or by adding or deleting application attributes.

To update information for a namespace:

1. Click the Namespaces tab.

2. In the Application Namespace column of the Namespaces page, click the namespace name you want to update.

3. On the Manage Namespace page, make your updates.

   If you had previously indicated no event handler was needed and now one is needed, select Yes, then click (^) to select the Handler Schema, Handler Package, and Handler Function.

   Click Add to add another application attribute. Enter the attribute name and its default value. Repeat this process to add each additional attribute and its default value.

   To delete one or more application attributes, select each one to be deleted in the Application Attributes section, and then click Delete.

4. Click Apply Changes to save your changes.

From the Namespaces tab, delete the session namespace you no longer need in your data security policy for this application.

To delete a namespace:

1. Click the Namespaces tab.

2. In the Application Namespace column of the Namespaces page, click the namespace name you want to delete.

3. In the Application Namespace section of the Manage Namespace page, click Delete, and then click OK to delete the namespace.

From the Settings tab, update the parameter settings for the LDAP user.

To update information for these parameter settings:

1. Click the Settings tab.

2. In the Name column of the Settings page, select the group name that is already entered; for example, select the LDAP_USER.

3. On the Manage Settings page, make your updates.

   Note:

   Change these settings carefully because an incorrect setting in the Parameters section can adversely affect the connection to the Directory server.

   The name of the LDAP group displays in the Settings section. You can make updates to the following fields in the Settings and Parameters sections:

   • Description - Description for the user name.

   • Host - Name of the host on which the Directory server is running.

   • Port - Directory server port number.

   • User - User entity location in the directory information tree (DIT)

   • Base - Naming context used to store the user entry in the Directory server.

   • Name Attribute - Name attribute and value pair.

   • ID Attribute - ID attribute and value pair. The ID attribute should be an attribute of the LDAP entry, which is specified by the base. It should globally identify the user. Normally, a GUID is used. For Oracle Internet Directory (OID), it should be orclguid; for Microsoft Active Directory (AD), it should be objectGUID.

   • Description Attribute - Description attribute and value pair.

   • SSL Wallet Location - Path to the wallet on the file system, such as, file:/home/mywallet. The word file: must be used as a prefix.

   • SSL Authentication Mode - Modes values are: 1 for no authentication required, 2 for one way authentication required, or 3 for two way authentication required.

4. Click Apply Changes to save your changes.

From the Settings tab, update the parameter settings for the LDAP group.

To update information for these parameter settings:

1. Click the Settings tab.

2. In the Name column of the Settings page, select the group name that is already entered; for example, select the LDAP_GROUP.

3. On the Manage Settings page, make your updates.

   Note:

   Change these settings carefully because an incorrect setting in the Parameters section can adversely affect the connection to the Directory server.

   The name of the LDAP group displays in the Settings section. You can make updates to the following fields in the Settings and Parameters sections:

   • Description - Description for the group name.

   • Host - Name of the host on which the Directory server is running.

   • Port - Directory server port number.

   • User - Group entity location in the directory information tree (DIT).

   • Base - Naming context used to store the group entry in the Directory server.

   • Name Attribute - Name attribute and value pair.

   • ID Attribute - ID attribute and value pair. The ID attribute should be an attribute of the LDAP entry, which is specified by the base. It should globally identify the group. Normally, a GUID is used. For Oracle Internet Directory (OID), it should be orclguid; for Microsoft Active Directory (AD), it should be objectGUID.

   • Description Attribute - Description attribute and value pair.

   • SSL Wallet Location - Path to the wallet on the file system, such as, file:/home/mywallet. The word file: must be used as a prefix.

   • SSL Authentication Mode - Modes values are: 1 for no authentication required, 2 for one way authentication required, or 3 for two way authentication required.

4. Click Apply Changes to save your changes.