5 Securing Oracle Data Service Integrator Resources

Oracle Data Service Integrator provides two types of security:

  • Managing Security at Runtime: Runtime security enables you to define policies that secure Oracle Data Service Integrator artifacts.

  • Controlling Administrative Access: Access control policies enable restricting Oracle Data Service Integrator Administration Console access based on user entitlements. Entitlements are predefined in the console and define the actions that a user can perform.

This chapter explains how you can configure and manage runtime security and access control for different users through the Oracle Data Service Integrator Administration Console. It contains the following sections:

5.1 Introduction to Oracle Data Service Integrator Security

To work with Oracle Data Service Integrator security features, you must first define and create users who will access the Oracle Data Service Integrator Administration Console. For more information about creating users, refer to Create Users in WebLogic Server Administration Console Online Help at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/taskhelp/security/DefineUsers.html.

To secure Oracle Data Service Integrator artifacts you can create runtime security policies. Oracle Data Service Integrator artifacts or resources include dataspaces, services, operations, library procedures, and data elements.

For more information on runtime security policies, refer to Section 5.2, "Understanding Runtime Security Policies."

After creating users in an Oracle Data Service Integrator-enabled WebLogic Server domain, you can control administrative access of these users by applying administrative access control policies. Access control on Oracle Data Service Integrator Administration Console is based on user entitlements.

Entitlements are assigned to users by a domain user, who is a super user for a particular domain. A domain user is created when you create an Oracle Data Service Integrator domain and specify the user name and password for it.

For more information on administrative access control, refer to Section 5.6, "Working with Administrative Access Control Policies."

5.2 Understanding Runtime Security Policies

The runtime security feature enables you to configure access to resources such as dataspaces, data services, operations, and data elements. For a secured resource, a requesting client must meet the condition of the runtime security policy applicable to that resource, whether accessing the resource through the typed mediator API, an ad hoc query, or any data access interface. Oracle Data Service Integrator exposes its deployed artifacts as resources that can be secured through runtime security policies.

For example, you can control access to an entire Oracle Data Service Integrator dataspace or just to a credit card number element within Customer_Order.ds.

When a request comes to a running Oracle Data Service Integrator instance for a secured resource, Oracle Data Service Integrator passes an identifier for the resource to WebLogic Server. WebLogic Server, in turn, passes the resource identifier, user name, and other context information to the authorization provider, such as XACMLAuthorizer. The provider evaluates the policy that applies to the resource. As a result of the evaluation, access to the resource is either permitted or blocked.

If the user does not satisfy the requirements of an element-level policy, the element is redacted from the result object, and therefore does not appear.

Note:

By default, WebLogic Server security uses the XACML Authorization Provider. Other authenticators can use any external resource necessary to implement the policy evaluation.

5.2.1 Definition of a Securable Resource

A securable resource is an Oracle Data Service Integrator artifact, such as a data service, operation, or element, to which you can apply a runtime security policy. The resources you can protect using runtime security include:

  • Dataspace: The policies apply to all the resources in the dataspace. However, if there are policies applied to a data service or operation, then the more specific policy applies.

  • Data Service: The policies apply to a data service and operations within that data service. However, if an individual operation has a policy applied to it, then the more specific policy applies.

  • Operations: The policy applies to individual data service operations in a dataspace. Data service operations include Oracle Data Service Integrator functions and procedures.

  • Data Elements: A policy can apply to individual elements within a data service Return type, such as the salary property of a customer.

After you secure individual resources, you can enable or disable security for the dataspace. Security policies are inherited. This means that security enabled at the dataspace level applies to all data services, operations, and elements within the dataspace.

However, if several policies apply to a particular resource, the more specific policy prevails. For example, a policy on an element supercedes a policy for the data service.

The hierarchy of Oracle Data Service Integrator artifacts is as follows:

  1. Dataspace

  2. Data Service

  3. Operations

  4. Element

Figure 5-2 illustrates the securable resources in an Oracle Data Service Integrator dataspace.

Figure 5-2 Securable Resources

Description of Figure 5-2 follows
Description of ''Figure 5-2 Securable Resources''

5.2.1.1 Allowing Anonymous Access

At the dataspace level, you can enable anonymous access by creating a policy. If you apply this policy, all users, including unauthenticated users, can access resources by default. For more information on creating runtime policies at the dataspace level, refer to Section 5.4, "Configuring Dataspace-Level Security."

The anonymous access policy works only with the WebLogic Authorization provider. The Oracle Data Service Integrator security policies are intended to work with the default WebLogic Authorization provider. If you are using another authorization provider, you will need to create policies using the facilities of the other provider.

For more information, see WebLogic Authorization Provider: Provider Specific in the Administration Console Online Help at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/pagehelp/Securitysecurityprovidersauthorizerproviderspecifictitle.html.

The Security Configurations tab on Oracle Data Service Integrator Administration Console provides the configurable runtime security policies. Setting up runtime security in Oracle Data Service Integrator Administration Console involves the following tasks:

  • Enabling Access Control

  • Configuring security policies for dataspaces, data services, operations, and elements.

  • Identifying data elements that you want to secure and then configure either security policies or custom XQuery security functions for the elements.

Oracle Data Service Integrator directly supports runtime security policies for its resources. The WebLogic Platform supports extensive security features that can be applied to your implementation as well, including encryption-based, transport-level security. For runtime security configuration, Oracle Data Service Integrator provides the following policies, called predicates, in Oracle Data Service Integrator Administration Console:

  • Role

  • Group

  • User

  • Access occurs on specified days of the week

  • Access occurs between specified hours

  • Context element's value is greater than a numeric constant

  • Deny access to everyone

  • Context element's value is equals a numeric constant

  • Access occurs before

  • Access occurs on the specified day of the month

  • Context element's value equals a string constant

  • Context element defined

  • Allow access to everyone

  • Access occurs after

  • Access occurs before the specified day of the month

  • Context element's value is less than the numeric constant

  • Access occurs after the specified day of the month

  • Server is in development mode

The security policies in the Oracle Data Service Integrator Administration Console are similar to the conditions used by WebLogic Server security. For more information on WebLogic Server security policies and conditions, refer to "Securing WebLogic Resources Using Roles and Policies" in the WebLogic Server documentation at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secwlres/sec_poly.html.

In addition to creating runtime security policies, you can create service accounts to map security configurations of external data sources such as web services and Java functions. This feature ensures secure storage of the credentials of external data sources and allows runtime identity mapping.

5.3 Creating and Applying Runtime Security Policies

Before you start creating and applying runtime policies, make sure that the Enable Access Control checkbox in the General tab is selected, as shown in Figure 5-3. This activates the security policy configurations. If access control is not selected, then security is not enabled for your dataspace. The General tab is available only at the dataspace level.

To enable access control:

  1. Select the Security Configurations tab and the dataspace from the navigation pane.

  2. Acquire the lock by clicking Lock & Edit.

  3. Click the General tab.

  4. Select Enable Access Control checkbox.

  5. To enable JDBC metadata access, select Enable JDBC Metadata Access Control.

  6. Click Save > Activate Changes.

    The steps to create and apply runtime security policy for a dataspace, data service, and operations are the same. However, you must make sure that you select the Oracle Data Service Integrator resource from the navigation pane. To create and apply the runtime security policy:

  7. Select the Security Configuration category.

  8. Click the Policy tab to start creating runtime policies for a dataspace, as shown in Figure 5-4.

    Figure 5-4 Security Configurations: Policy Tab

    Description of Figure 5-4 follows
    Description of ''Figure 5-4 Security Configurations: Policy Tab''

  9. Click Add Conditions on the Policy tab. The Choose a Predicate page is displayed.

  10. Select the predicate from the Predicate List drop down. For example, select User and click Next.

  11. The next page that appears, depends on the predicate you select. If you select User predicate, the page show in Figure 5-5 is displayed.

    Note:

    If you select the User predicate, it implies that you are allowing a particular user to access the dataspace. Make sure that this user is authenticated by WebLogic Server.

  12. Specify the user name in the User Argument Name field, for example User A, and click Add. This adds the argument to the text box adjacent to the Remove button.

    Figure 5-5 User Predicate Arguments Page

    Description of Figure 5-5 follows
    Description of ''Figure 5-5 User Predicate Arguments Page''

  13. Click Finish. This adds the policy to the policy conditions applied to the dataspace.

5.4 Configuring Dataspace-Level Security

This section discusses how to configure dataspace-level security. It includes the following topics.

You can configure runtime policies that would ensure access to users who are assigned entitlements to access the entire dataspace. At the dataspace level, the Security Configuration tab provides the following tabs:

  • General: This tab provides the options to enable secured access to Oracle Data Service Integrator resources and also to JDBC metadata. To access these options, click Lock & Edit to acquire the lock. It includes the following options:

    • Enabling Access Control: Enabling access control activates checking security policies throughout the dataspaces within the domain. It ensures that access to any resource is determined by the policy on that resource.By default, access control is not enabled.

    • Enabling JDBC Metadata Access Control: You can control metadata accessed through SQL by selecting the Enable JDBC Metadata Access Control option. This option allows Oracle Data Service Integrator metadata access to users based on their access rights at the JDBC driver level. Selecting this option ensures that users are able to list only those tables and procedures that they are authorized to use. By default, this option is not enabled.

      Note:

      If an access policy is time-dependent or is changed and the metadata access control option is enabled, you may not be able to access the tables and procedures that had been listed.

    • Export Access Control Resources: This feature allows you to export the securable resource IDs within a dataspace to a text file format. However, it does not export the console configurations while exporting the Oracle Data Service Integrator resources. This is helpful in determining the dataspace structure and defining policies on different systems, which may not be using the same authorization provider or are working on different servers.

    For more information, refer to Section 5.4.5, "Exporting Access Control Resources."

  • Policy: This tab allows you to edit policies if the default authorization provider, XACMLAuthorizer, is used. It provides the following information:

    • Resource Name: The resource for which you need to add a runtime security policy.

    • Providers: The authorization provider that WebLogic Server uses.

    • Policy Conditions: List of policies that have been applied to the resource.

    • Overwritten Policy: Any policy

    If a third-party authorization provider is used, then this tab displays a message as follows:

    "Policies for Oracle Data Service Integrator domain have to be defined in the configured external policy provider."

    For more information about creating and applying security policies, refer to Section 5.3, "Creating and Applying Runtime Security Policies."

  • XQuery Functions for Security: An XQuery function for security enables you to specify custom security policies that can be applied to data elements. In particular, security XQuery functions are useful for creating data-driven policies (policies based on data values). For example, you can block access to an element if the order amount exceeds a given threshold. For more information, refer to Section 5.4.2, "Working with XQuery Functions for Security."

  • Service Accounts Configuration: Service accounts represent a mapping of user credentials between an Oracle Data Service Integrator user and the user of an external data source, such as a web service or Java function. This mapping is stored as a part of the dataspace configuration and ensures secure storage of external identity credentials. You can associate service accounts with a number of external data sources to perform runtime identity mapping. For more information, refer to Section 5.4.4, "Understanding and Using Service Accounts."

5.4.1 Specifying Runtime and WSDL Access Service Accounts

Service accounts enable you to create a mapping between local WebLogic users and remote external data source users. This enables you to use Oracle Data Service Integrator to store user credentials to external data sources. You can create service accounts using Oracle Data Service Integrator Console.

You can assign service accounts to physical sources such as delimited files, Java functions, web services, and XML files using the Oracle Data Service Integrator Console

Note:

You do not need to assign service accounts to physical sources based on relational databases. Oracle Data Service Integrator uses built-in support in WebLogic Server to provide JDBC identity mapping between local WebLogic users and remote data source users.

You can use the Oracle Data Service Integrator Console to assign the following types of service accounts to physical sources:

Table 5-1 Services Accounts Assignable to Physical Sources

Type Description

Runtime Service Account

The service account mapping to enable runtime access to the physical source.

WSDL Access Service Account

The service account mapping to use to access the WSDL file. This option is only available with physical sources based on web services.

For a web service-based data source any of the following combinations are acceptable. (The list is not exhaustive.)

  • The same service account is used for runtime and WSDL access.

  • Different service accounts are used for runtime and WSDL access.

  • A service account is used for runtime but no service account is used for WSDL access.

  • No service accounts are used.

5.4.1.1 Specifying Service Accounts

To specify the service account for a physical source:

  1. Click the Physical Sources tab in the category list, select the dataspace in the navigation tree, and click the Physical Source Properties in the workspace content area.

    You can specify service accounts for delimited files, Java functions, web services, and XML files.

    Figure 5-6 Physical Source Properties Tab

    Description of Figure 5-6 follows
    Description of ''Figure 5-6 Physical Source Properties Tab''

  2. Click Lock & Edit to acquire the lock.

  3. Choose the Runtime Service Account for the delimited file, Java function, or XML file, using the drop-down list.

  4. Choose the WSDL Service Account for the web service using the drop-down list.

  5. Click Save > Activate Changes.

5.4.2 Working with XQuery Functions for Security

This section describes how to work with XQuery functions for security. It includes the following topics:

XQuery security functions allow data-driven security of Oracle Data Service Integrator resources. At the dataspace level, you can create and maintain XQuery functions to ensure that data elements are returned only when the conditions are met. However, to associate these functions to data service elements, go to the data service and specify the element for which the function applies.

Note:

If both a standard security policy and an XQuery function applies to a given data element, the results of both policy evaluations must be true for access to be permitted (logical and is applied to the results).

Applying data-driven security policies involves the following steps:

  1. Identify the element as a secured element. (For more information, see Section 5.5.4, "Configuring Data Element-level Security.")

  2. Create a security XQuery function to define the data-level security. (For more information, see Section 5.4.2.1, "Creating an XQuery Function for Security.")

  3. Apply a security XQuery function to the data element. (For more information, see Section 5.4.2.2, "Applying an XQuery Function for Security.")

5.4.2.1 Creating an XQuery Function for Security

You can create one or more XQuery functions to apply to data elements within a dataspace.

To create an XQuery function for security:

  1. Click Security Configurations tab and select the dataspace in the Navigation tree.

  2. Click Lock & Edit to acquire the lock and then select the XQuery Functions for Security tab.

    Figure 5-7 Security XQuery Functions

    Description of Figure 5-7 follows
    Description of ''Figure 5-7 Security XQuery Functions''

  3. Add the XQuery function body in the text area of the tab, as shown in Figure 5-7. The following code sample is used in this illustration:

    import schema namespace t1 = 'ld:DataServices/CUSTOMER_ORDER' at 
   'ld:DataServices/Schema/CUSTOMER_ORDER.xsd';
declare namespace f1 = "ld:CUSTOMER_ORDER";
declare function f1:secureOrders($order as
      element(f1:CUSTOMER_ORDER)) as xs:boolean {
   if (fn-bea:is-access-allowed("CUSTOMER_ORDER/LimitAccess",
      "ld:CUSTOMER_ORDER.ds")) then
      fn:true()
   else if ($order/TotalOrderAmount lt
      (fn-bea:get-property("total_order_amount", "1000000") cast as
      xs:decimal)) then
      fn:true()
   else
      fn:false()
};

    Notice that the function uses the Oracle extension XQuery function is-access-allowed(). This function tests whether a user associated with the current request context can access the specified resource, which is denoted by an element name and a resource identifier.

    Oracle Data Service Integrator provides the following additional convenience functions for security purposes:

    • is-user-in-group ($arg as xs:string) as xs:boolean

      Checks whether the current user is in the specified group.

    • is-user-in-role ($arg as xs:string) as xs:boolean

      Convenience method that checks whether the current user is in the specified role.

    • userid() as xs:string

      Returns the identifier of the user making the request for the protected resource.

      For details on creating XQuery functions, see the XQuery and XQSE Developer's Guide at http://download.oracle.com/docs/cd/E13162_01/odsi/docs10gr3/xquery/index.html.

  4. Click Compile and ensure that the function compiles successfully.

  5. Click Save > Activate Changes to store the XQuery function.

A security XQuery function must be applied to a data element for it to take effect. For more information, see Section 5.4.2.2, "Applying an XQuery Function for Security." The functions are applied to elements by qualified function name. The only requirement for the function is that it returns a Boolean value and that the name should be qualified by a namespace URI.

5.4.2.2 Applying an XQuery Function for Security

You can use XQuery functions for security to control access to data elements. After you define the XQuery function for security, as described in Section 5.4.2.1, "Creating an XQuery Function for Security," you must apply the function to the corresponding data element for it to take effect.

In addition, you define policies for securing the data elements, which provide additional security along with the XQuery functions for security. For more information, refer to Section 5.5.4, "Configuring Data Element-level Security."

To make any changes to the security configurations of a data element, you must first acquire the lock by clicking Lock & Edit. To apply the XQuery function for security to a data element:

  1. Select the Security Configuration tab from the navigation pane and then click the data service associated with the data element that you need to secure.

  2. Click the Secured Elements tab and select the checkbox next to the data element to which you want to apply a custom function.

  3. Click Save and then click Activate Changes. This data element is now visible under the data service in the navigation tree.

  4. Select the data element from the navigation tree and click the Secured Elements Configuration tab. This tab allows you to specify the qualified function name and namespace URI for the XQuery function that you want to associate with the data element, as shown in Figure 5-8.

    Figure 5-8 Applying XQuery Functions for Security

    Description of Figure 5-8 follows
    Description of ''Figure 5-8 Applying XQuery Functions for Security''

  5. If you want to specify a default value for the element or attribute, then select the User Default Value checkbox and specify the default value in the Default Value box.

    This option allows you to assign a constant value for the element or attribute. However, it supports only primitive types, so you cannot have a default value for complex types.

    Note:

    If you select this check box, then it is mandatory to specify the default value for the resource.

  6. Specify the namespace URI and local name of the XQuery function that you have created.

  7. Click Add > Save > Activate Changes. This completes the association of the data element with the XQuery function for security.

5.4.3 Data Redaction Options for Data Elements

This section describes data redaction options for data elements. It includes the following topics:

Data redaction is the process of obscuring or removing information from a data result prior to displaying the result. Oracle Data Service Integrator offers the following forms of data redaction for secured elements and attributes:

  • Optional elements and attributes may be omitted from the result

  • Simple-typed elements and attributes may have their values substituted by a fixed, default value in the result

  • String-valued elements and attributes may have their values encrypted using a secure, identity-preserving transformation

The first two forms map originally distinct fields in multiple data instances to the same redacted representation. This means that these methods are not suitable for certain applications, such as data analytics, which require that fields maintain their identity so that standard operations such as GroupBy or Join can be performed based on the fields.

The third form, encrypting the data, preserves the identity of the field enabling you to perform a wider range of operations on the data. Oracle Data Service Integrator offers secure encryption-based data redaction that you can use to encrypt elements in the results of read and navigate functions declared in entity data services.

5.4.3.1 Data Redaction Conditions

The following describes the conditions related to selecting a data redaction option:

Table 5-2 Data Redaction Conditions

Option Description Discussion

Remove element

Omits the element or attribute from the result.

Available if the element or attribute is optional.

Use default value

Uses the specified default value instead of the actual result.

Available if the element or attribute is a leaf node (simple type).

Encrypt value using the WebLogic Server encryption service

Encrypts the result using the WebLogic Server encryption service.

Available if the element or attribute is of type (or sub-type of) xs:string.

5.4.3.2 Specifying the Data Redaction Behavior

You can specify the redaction behavior for data elements to secure information against unauthorized access.

To specify the redaction behavior for a data element:

  1. Click the Lock & Edit button.

  2. Select the Security Configuration tab from the navigation pane and click the data service associated with the data element that you need to secure.

  3. Click the Secured Elements tab and select the checkbox next to the data element for which you want to specify the redaction behavior.

  4. Click Save. This data element is now visible under the data service in the navigation tree.

  5. Select the data element from the navigation tree and click the Secured Elements Configuration tab.

    Figure 5-9 Secured Elements Configuration Tab

    Description of Figure 5-9 follows
    Description of ''Figure 5-9 Secured Elements Configuration Tab''

  6. Select the redaction behavior for the data element and set the default value if necessary. Click Save > Activate Changes.

    • To apply encryption-based data redaction to the element, select the Encrypt value using the WebLogic Server encryption service button.

    • To have the system omit the element or attribute, select the Remove element button.

    • To specify a default value for the element or attribute, select the Use default value button and specify the default value. This assigns a constant value for the element or attribute. For example, assigning "000-00-0000" as the default value for an element named SSN causes this value to appear every time the SSN element is returned. Note however that this feature supports only primitive types, so you cannot specify a default value for complex types. Also, if you select the Use default value button, you must specify a default value for the resource.

5.4.3.3 Encryption-Based Data Redaction Examples

This section provides several examples showing how encryption-based data redaction works when performing common operations.

Example Data Service Functions

The examples in this section make use of the following data services:

Entity data service CustomerDS—The data service returns information about a customer conforming to the following schema:

CUSTOMER
   SSN: xs:string
   FIRST NAME: xs:string
   LAST NAME: xs:string
   CUSTOMER_SINCE: xs:date

The information is exposed through the public read function getCUSTOMERS(), which returns data similar to the following:

<SSN>123-45-6789</SSN>
   <FIRST_NAME>John</FIRST_NAME>
   <LAST_NAME>Smith</LAST_NAME>
   <CUSTOMER_SINCE>2007-10-10</CUSTOMER_SINCE>
</CUSTOMER>

Entity Data Service OrderDS

The data service returns information about a customer order conforming to the following schema:

ORDER
   ORDER_ID: xs:integer
   CUSTOMER_SSN: xs:string
   DATE: xs:date
   STATUS: xs:string

The information is exposed through the public read function getORDERS(), which returns data similar to the following:

<ORDER>
   <ORDER_ID>1000</ORDER_ID >
   <CUSTOMER_SSN>123-45-6789</CUSTOMER_SSN>
   <DATE>2007-10-10</DATE>
   <STATUS>CLOSED</STATUS>
</ORDER>
<ORDER>
   <ORDER_ID>2000</ORDER_ID >
   <CUSTOMER_SSN>123-45-6789</CUSTOMER_SSN>
   <DATE>2007-11-11</DATE>
   <STATUS>OPEN</STATUS>
</ORDER>

Example Results

This section provides examples of encryption-based data redaction.

Projection of an Encrypted Field

Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS, the direct function call getCUSTOMERS() returns the following:

<CUSTOMER>
   <SSN>sjdlkggdlaklakskjfgk</SSN>
   <FIRST_NAME>John</FIRST_NAME>
   <LAST_NAME>Smith</LAST_NAME>
   <CUSTOMER_SINCE>2007-10-10</CUSTOMER_SINCE>
</CUSTOMER>

Note that the value of the SSN field is encrypted and unique for each distinct SSN.

Predicate Against an Encrypted Field

Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS, the following XQuery query returns ():

for $x in p:getCUSTOMERS()
where $x/SSN eq "123-45-6789"
return $x

This is because a match is attempted between an unencrypted value and the encrypted SSN value.

Outer Join on Encrypted Fields

Consider the following XQuery query that performs an outer join:

for $x in p:getCUSTOMERS()
return
<CUSTOMER>
   <SSN>{fn:data($x/SSN)}</SSN>
   {
   for $y in q:getORDERS()
   where $x/SSN eq $y/CUSTOMER_SSN
   return
      <ORDER_ID>{fn:data($y/ORDER_ID)}</ORDER_ID>
   }
</CUSTOMER>

Assuming that encryption-based data redaction has been configured for both the SSN field in CustomerDS and the CUSTOMER_SSN field in OrderDS, the query returns the following:

<CUSTOMER>
   <SSN>sjdlkggdlaklakskjfgk</SSN>
   <ORDER_ID>1000</ORDER_ID >
   <ORDER_ID>2000</ORDER_ID >
</CUSTOMER>

Notice that the outer join is performed as if encryption was not set. Note also that the value of the secured element in the result is encrypted.

Join Encrypted Field With Non-Encrypted Field

Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS but not on data service OrderDS, consider the following XQuery query that joins an encrypted field with a non-encrypted field:

for $x in p:getCUSTOMERS()
return
<CUSTOMER>
   <SSN>
      {fn:data($x/SSN)}
   </SSN>
   {
   for $y in q:getORDERS()
   where $x/SSN eq $y/CUSTOMER_SSN
   return
      <ORDER_ID>
         {fn:data($y/ORDER_ID)}
      </ORDER_ID>
   }
</CUSTOMER>

The query returns ().

Note that the outer join fails to return any results because the encrypted value of SSN does not match the non-encrypted value of CUSTOMER_SSN.

Group by an Encrypted Field

Consider the following SQL query that includes a group by clause:

SELECT CUSTOMER_SSN, COUNT(*y)
FROM ORDERS
GROUP BY CUSTOMER_SSN

Assuming that encryption-based data redaction has been configured for the CUSTOMER_SSN field in data service OrderDS and the getOrders() function has been mapped to the SQL table ORDERS, the SQL query returns the following:

(sjdlkggdlaklakskjfgk, 2)

Notice that the group by clause performs as if encryption was not set. Note also that the value of the secured column in the result is encrypted.

5.4.4 Understanding and Using Service Accounts

Service accounts provide the option to store user credentials for external data sources. It provides a mapping between the local WebLogic user and a remote external data source user by configuring the user credentials within the Oracle Data Service Integrator Administration Console.

You can configure service accounts for web services and Java functions. For JDBC identity mapping, Oracle Data Service Integrator depends on Oracle WebLogic Server built-in support.

Service accounts provide different types of mappings, which include:

  • Static: This mapping option enables you to map all Oracle Data Service Integrator users, including unauthenticated users, to a single external data source user.

  • Mapping: This option enables you to create a mapping of an Oracle Data Service Integrator user to an external data source user. You can also map multiple Oracle Data Service Integrator users to a single external data source user. For unauthenticated users you may define a mapping, otherwise an error will occur when the unauthenticated user tries to access Oracle Data Service Integrator.

  • Identity Mapping: This option enables you to create a mapping between external data source users and identically-named authenticated Oracle Data Service Integrator users, supplying the passwords of only the external data source users.

    Note:

    After you create and define the type of a service account, you cannot change it. If you have to change a service account type, delete the account and create a new one.

5.4.4.1 Creating a Service Account

To create a service account:

  1. Click the Security Configurations tab in the category list, select the dataspace in the navigation tree, and click the Service Accounts tab in the workspace content area.

  2. Click Lock & Edit to acquire the lock.

  3. Click New. This opens the Create a New Service Account page, as shown in Figure 5-10.

  4. On this page, specify the following details:

    • Resource Name: Name of the service account.

    • Resource Description: A description of the service account. This is optional.

    • Resource Type: Select the type of the service account from the list of available options including Static, Mapping, and Identity Mapping.

    Figure 5-10 Create a New Service Account Page

    Description of Figure 5-10 follows
    Description of ''Figure 5-10 Create a New Service Account Page''

    Note:

    Based on the selected resource type, the Next button is enabled.

  5. If you select the resource type as Static:

    1. Click Next.

    2. On the next page, specify the user name and password for that account and click Finish, as shown in Figure 5-11.

    Figure 5-11 Creating a Static Service Account

    Description of Figure 5-11 follows
    Description of ''Figure 5-11 Creating a Static Service Account''

  6. If you select the resource type as Mapping and click Next, a new page is displayed, as shown in Figure 5-12.

    Figure 5-12 Creating a Service Account of the Mapping Type

    Description of Figure 5-12 follows
    Description of ''Figure 5-12 Creating a Service Account of the Mapping Type''

    On this page, you can define the remote (external data source) users.

    1. Specify the remote user name and password in the Remote User Name and Password fields, respectively, of the Enter Authorized Remote User table.

    2. Click Add. This adds the users to the Remote Users table. Using the Remote Users table you can edit the password or delete a user, as required.

    3. Click Next after adding the remote users. The next page enables you map the local users to remote users, as shown in Figure 5-13.

      Figure 5-13 Local User to Remote Mapping

      Description of Figure 5-13 follows
      Description of ''Figure 5-13 Local User to Remote Mapping''

    4. Specify the local user name in the Local User Name field and select the corresponding remote user from the Remote User Name list.

    5. Click Add. This creates the local to remote user mapping.

    6. To map all unauthenticated (anonymous) users to a particular remote user, click the Map Anonymous Requests checkbox and then choose the remote user from the drop-down list.

    7. In case you want to provide a default mapping for all authenticated user that do not have an explicit mapping to the remote user, click the Map Other Authenticated Requests checkbox and choose the remote user from the drop-down list.

    8. Click Finish.

  7. If you select the resource type as Identity Mapping and click Next, a page is displayed, as shown in Figure 5-13. This page is identical to the page displayed when you select Mapping as the resource type.

    On this page, you can define the authorized remote (external data source) users, and add them as authenticated external data source users.

    1. Specify the remote user name and password in the Remote User Name and Password fields, respectively, of the Enter Authorized Remote User table.

    2. Click Add. This adds the users to the Remote Users table. Using the Remote Users table you can edit the password or delete a user, as required.

    3. Click Next after adding the remote users. The next page enables you to map anonymous requests or other authenticated requests to remote users.

    4. To map all unauthenticated (anonymous) users to a particular remote user, click the Map Anonymous Requests checkbox and then choose the remote user from the drop-down list.

    5. In case you want to provide a default mapping for all authenticated users that do not have an explicit mapping to the remote user, click the Map Other Authenticated Requests checkbox and choose the remote user from the drop-down list.

    6. Click Finish. This creates a mapping between the defined external data source users and the identically-named authenticated Oracle Data Service Integrator users.

    Figure 5-14 Mapping Anonymous Requests or Other Authenticated Requests

    Description of Figure 5-14 follows
    Description of ''Figure 5-14 Mapping Anonymous Requests or Other Authenticated Requests''

  8. Click Activate Changes.

5.4.5 Exporting Access Control Resources

Authorization is the process whereby the interaction between users and resources are limited to ensure integrity, confidentiality, and availability. WebLogic uses resource identifiers to identify deployed Oracle Data Service Integrator artifacts, such as dataspaces, data services, and operations. This identifier is used to associate a client request to any security policies configured for the requested resource.

Resource identifiers are managed for you when you use the default WebLogic Authorization provider and the Oracle Data Service Integrator Administration Console to configure your policies. In particular, resource identifiers already exist for Oracle Data Service Integrator dataspaces, data services, and data service operations. In addition, when you choose elements to be secured in the console, an identifier is generated for the element.

However, when using a custom authorizer, you must know the resource identifiers for your deployment and configure policies for the resources in the form expected by the other authorization module. This means that you need to identify the element resources that need to be protected.

The WebLogic security documentation provides details on how to connect another security authenticator to WebLogic Server. For more information, see WebLogic Authorization Provider in the Administration Console Online Help at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/pagehelp/Securitysecurityprovidersauthorizerconfigcommontitle.html.

You can view the list of resource identifiers by exporting the access control resources from the Oracle Data Service Integrator Administration Console.

To export the file:

  1. Select the dataspace in the navigation pane and select the General tab from the Security Configuration category.

  2. Click Lock & Edit and then click Export Access Control Resources if you want to export the current session values of the dataspace.

  3. If you want to export the core values, then click Export Access Control Resources without acquiring the lock.

  4. Save the text file.

    An example of a portion of the file follows:

    <ld type="admin"><app>DOMAIN</app></ld>
<ld type="admin"><app>ADMIN</app></ld>
<ld type="admin"><app>MONITOR</app></ld>
<ld type="admin"><app>BROWSER</app></ld>
<ld type="admin"><app>ADMIN</app><ds>DSP_TEST</ds></ld>
<ld type="admin"><app>MONITOR</app><ds>DSP_TEST</ds></ld>
<ld type="admin"><app>BROWSER</app><ds>DSP_TEST</ds></ld>
<ld type="app"><app>DSP_TEST</app></ld>
<ld type="service"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_
CARD.ds</ds><res>{ld:CREDIT_CARD}CREDIT_CARD:0</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}createCREDIT_CARD:1</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_
CARD.ds</ds><res>{ld:CREDIT_CARD}deleteCREDIT_CARD:1</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_
CARD.ds</ds><res>{ld:CREDIT_CARD}updateCREDIT_CARD:1</res></ld>
<ld type="service"><app>DSP_TEST</app><ds>ld:CUSTOMER.ds</ds></ld>

The format of a resource identifier is shown in Figure 5-15.

Figure 5-15 Resource Identifier Format

Description of Figure 5-15 follows
Description of ''Figure 5-15 Resource Identifier Format''

The type can be admin, service, or function. The resource can be any of the following:

  • Function: A data service function, for example,

    {ld:DataServices/ElectronicsWS/getProductList}getProductList:1

  • User-defined or administrative entity: A custom entity, such as a protected element or an arbitrary label defined in a data service that is used with fn-bea:is-access-allowed operation.

These are generated when you select an element in the Secured Element tab of the Oracle Data Service Integrator Administration Console.

5.5 Configuring Data Service and Operation-Level Security

This section discusses how to configure data service and operation-level security. It includes the following topics:

A data service has several operations, including one or more read, create, update, delete, navigation, and library operations. The security policies that you apply at the data service level apply to data service operations and data elements. You can also select the data elements that you want to secure at the data service level.

Operation-level security policies enable you to control:

  • User access to data service operations. It enables you to set stricter controls on the ability to change data, for example, compared to the ability to read data.

  • Access time of data service operations. Enables you to control the time when a particular operation can or cannot be accessed.

Make sure that you configure policies on the data service resources that are accessed directly by the user. Security policies on data services that are used by other data services are not inherited by the calling data service. This means that if a data service with a secured resource is accessed through another data service, the policy is not evaluated against the caller. For more information, refer to Section 5.5.3, "Creating and Configuring Security Policies for Operations."

Data service operations are identified by name and number of parameters for setting security configurations. If you modify the number of parameters, you will need to reconfigure the security settings for the operation.

5.5.1 Creating Data Service Runtime Security Policies

The steps to create the security policy at the data service and operation level are the same as the dataspace level. Refer to Section 5.3, "Creating and Applying Runtime Security Policies" for details.

At the data service level, you can select all the data elements in a data service by selecting the top-level element (Customers in Figure 5-16) or individual data elements that you want to secure using the Secured Elements tab.

For example, if you create an XQuery function for security and you want to associate it with a data element, you can select the data element from the Secured Elements tab and then configure the data-element level security. (For more information about XQuery function for security, refer to Section 5.4.2, "Working with XQuery Functions for Security.")

Note:

You should only secure the root element of a data service if you are confident that none of the elements used by read functions in the service must return a value. Since a secured element does not return a value, a schema which requires that one or more values be returned will fail with a runtime error. Alternatively, you can modify the schema so that elements are optionally returned.

To select the data element to be secured:

  1. Acquire the lock and select the data service.

  2. Select the Secured Elements tab, as shown in Figure 5-16.

  3. Select the data element that you want to configure for security.

  4. Click Save > Activate Changes. Notice that the selected element is now included in the navigation tree under the data service, as shown in Figure 5-16.

Figure 5-16 Secured Data Element in the Navigation Tree

Description of Figure 5-16 follows
Description of ''Figure 5-16 Secured Data Element in the Navigation Tree''

To apply security policy to the data element, select the element from the navigation tree. You can also select the secured element using the Secured Elements tab. For more information, refer to Section 5.5.4, "Configuring Data Element-level Security."

5.5.2 Cascading Element-Level Security to Child Elements

Using the Oracle Data Service Integrator Administration Console, you can select the data elements that you want to secure at the data service level. When selecting a complex node, Oracle Data Service Integrator further enables you to optionally cascade the selection to all child elements and attributes of the complex node.

To select a complex node and cascade the selection:

  1. Acquire the lock and select the data service.

  2. Select the Secured Elements tab

    Figure 5-17 Securing Data Elements at the Data Service Level

    Description of Figure 5-17 follows
    Description of ''Figure 5-17 Securing Data Elements at the Data Service Level''

  3. Select the Cascade selection to children nodes check box.

  4. Select the data element that you want to configure for security.

  5. Click Save > Activate Changes.

    Note:

    The cascade functionality is just a user interface usability feature. All the elements secured in this way are still independent of the parent element. You will have to configure security policies, redaction modes for all of them separately.

5.5.3 Creating and Configuring Security Policies for Operations

To set runtime security policy for an operation:

  1. Select the operation from the navigation tree and click the Function Configuration tab.

  2. Select the Always Secured checkbox and click Save as shown in Figure 5-18.

    Figure 5-18 Function Configuration Tab

    Description of Figure 5-18 follows
    Description of ''Figure 5-18 Function Configuration Tab''

This setting ensures that every time this operation is accessed, the runtime policy is adhered to. Consider the following example:

  • Operation 1 (fn1) has a runtime policy to allow access to user1 or user2.

  • Operation 2 (fn2) has a runtime policy to allow access to user2 only and the operation configuration is set to Always Secured.

  • fn1 invokes fn2.

In this scenario, if you access fn1 using user1, then access will be denied because the runtime security policy configuration does not allow user1 to access fn2.

If you do not select the Always Secured check box for fn2, then you will be able to access fn1 if using either user1 or user2 because the system will check the security policy for fn1 only and not fn2.

5.5.4 Configuring Data Element-level Security

Element-level security associates a security policy with a data element for the Return type within a data service. If the policy condition is not met, the corresponding data is not included in the result.

When configuring element-level security, you first identify the element as a securable resource, then set a policy on the resource.

The data element security policy can be configured using the steps described in Section 5.3, "Creating and Applying Runtime Security Policies."

To associate an XQuery function for security with a corresponding data element, select the Secured Elements Configuration tab and follow the steps mentioned in Section 5.4.2.2, "Applying an XQuery Function for Security."

Note:

Element-level security is only applied when all of the following conditions are met:

  • The data is being delivered across the "client-server boundary".

  • The security is applied to a data service that is directly accessed by a valid client process. In other words, element-level security policies are not "inherited" from underlying or invoked data services.

  • The element being secured is accessed from a client using a read or navigation operation or an ad hoc query.

5.5.4.1 Additional Data Element Security Considerations

To ensure the security of elements, you need to manage and layer data services properly. This means being careful not to create insecure holes in the layers and not depending on security settings for data services which are not being directly invoked by the client.

Note:

Secured elements, in general, should never offer public read or navigate functions that accept a secured element value as an input argument as this can permit guessing-style attacks to reveal otherwise secure data.

5.5.5 Securing Native Web Services

You can set the security policies for native web services using the Basic Auth Required property in the Eclipse IDE. You can create runtime security policies for a native web service and then set this property to true. This applies the security policy for the native web service. For more information about the Basic Auth Required property, refer to the Add Security Resources to Data Services topic in the Designing Logical Data Services section of the Data Services Developer's Guide at http://download.oracle.com/docs/cd/E13162_01/odsi/docs10gr3/datasrvc/Designing Logical Data Services.html.

The Service Explorer in Oracle Data Service Integrator Administration Console allows you to check if the Basic Auth Required property is set to true or false.

To view information about this property in the Service Explorer:

  1. Click the Service Explorer category. The General tab is displayed as shown in Figure 5-19.

    Figure 5-19 Basic Auth Required Property Information in Service Explorer

    Description of Figure 5-19 follows
    Description of ''Figure 5-19 Basic Auth Required Property Information in Service Explorer''

  2. Select the native web service from the navigation tree. In this case, the Basic Auth Required property is set to true. This implies that some security policy is applied to SERVICE_CASE.ws, which the native web service.

5.5.6 Creating Security Policies for User-Defined Security Resources

User-defined security resources are created in the Eclipse IDE Property Editor, as shown in Figure 5-20.

Figure 5-20 Oracle Data Service Integrator IDE Property Editor: User-Defined Security Resources

Description of Figure 5-20 follows
Description of ''Figure 5-20 Oracle Data Service Integrator IDE Property Editor: User-Defined Security Resources''

For more information about setting the security resource values, refer to Declare a Security Resource in Data Services Developer's Guide at http://download.oracle.com/docs/cd/E13162_01/odsi/docs10gr3/datasrvc/index.html.

After you assign a value to the security resource, you can create runtime security policies for the user-defined security resource. In the preceding figure, ordertime is the value of the security resource. After you deploy the dataspace, this resource is displayed in Oracle Data Service Integrator Administration Console.

You can create a runtime security policy for the ordertime security resource using the console.

5.6 Working with Administrative Access Control Policies

This section describes how to work with administrative access control policies. It includes the following topics:

Administrative roles require entitlements to access Oracle Data Service Integrator Administration Console. These entitlements can be assigned through the Administrative Access Control category, as shown in Figure 5-21.

Figure 5-21 Administrative Access Control Tab

Description of Figure 5-21 follows
Description of ''Figure 5-21 Administrative Access Control Tab''

A domain user, who is the super user for the console, assigns entitlements to users. In addition to the domain entitlement, other predefined entitlements are admin, monitor, and browser, which allow access to information for different categories and resources. The hierarchical structure of the entitlements is as follows:

  1. Domain

  2. Admin

  3. Monitor

  4. Browser

This hierarchy implies that the domain entitlement allows you to perform all the tasks on Oracle Data Service Integrator Administration Console, depending on whether the domain entitlement is for all the dataspaces within a domain or a particular dataspace. However, other entitlements cannot perform all the tasks that can be performed by a user with domain entitlement.

For example, you can set the administrative access control policies only if you have domain entitlement. Similarly, the admin entitlement allows you to perform more tasks on a dataspace than monitor or browser entitlements.

Note:

Entitlements can be assigned at the dataspace level or for all the dataspaces. For example, for User A, you can assign admin entitlement for DS1, monitor entitlement for DS2, and browser entitlement for DS3. Alternatively, you can assign the Admin entitlement for all the dataspaces within the domain to User A. For more information, refer to Assigning Entitlements.

A default domain user is created on WebLogic Server when you create the Oracle Data Service Integrator domain. There can be more than one domain user for the console and one domain user can create other domain users.

Note:

By default, an Admin role is created for a domain user in Oracle Data Service Integrator Administration Console which is mapped from WebLogic Server Administrator role, as shown in Figure 5-21.

Table 5-3 lists the tasks that can be performed by a user for each entitlement.

Table 5-3 Tasks Allowed for Entitlements

Entitlement Categories and Resources Available

Domain

The domain user for a dataspace can perform all the tasks on the Oracle Data Service Integrator Administration Console. Some of the most important tasks that a domain user can perform include the following:

  • Creating, deploying, and deleting dataspaces

  • Creating users with domain, admin, monitor, browser entitlements

  • Editing and updating configurations

  • Acquiring lock from a user forcibly

  • Viewing all tabs in the category list, including the Administrative Access Control tab

  • Configuring auditing options

  • Manage data cache

Note: Only a domain user can acquire a lock forcibly from another user, regardless of the user entitlement. This means that the one domain user can forcibly acquire the lock from another domain user also.

Admin

Most of the information available to an admin user for a dataspace is the same as the domain user. However, an admin user cannot create or delete dataspaces and cannot assign entitlements. Therefore, when you log into the console with admin entitlement, then the Administrative Access Control tab will not be available.

Monitor

A monitor for a dataspace cannot make any changes in the Oracle Data Service Integrator Administration Console. Therefore, the change center is disabled for the dataspace for which the user has monitor entitlements. The System Administration tab for a monitor user does not provide any options. A monitor user can view the following on the console:

  • Data cache, queries and updates available through the Operations category

  • For the dataspace, a monitor user can export the static mediator client jar file using the General tab.

Browser

A browser user has the least control over the Oracle Data Service Integrator Administration Console. This user entitlement can only browse through the console. The change center is disabled for this user. However, like a monitor user, a browser user can also export the static mediator client JAR file.

5.6.1 Assigning Entitlements

Entitlements are created for users that are created on WebLogic Server 10gR3 and can be managed through the WebLogic Server Administration Console.

To assign an entitlement:

  1. Log into the Oracle Data Service Integrator Administration Console using the domain user name and password.

  2. Select the Administrative Access Control category.

  3. If you want to assign entitlement for a specific dataspace, then from the navigation tree, select the dataspace listed under the entitlement. For example, if you want to assign admin entitlement for dataspace DS1, then select DS1 listed under the Admin entitlement, as shown in Figure 5-22.

    Figure 5-22 Assigning Entitlement for a Dataspace

    Description of Figure 5-22 follows
    Description of ''Figure 5-22 Assigning Entitlement for a Dataspace''

    You can also assign an entitlement to a user for all dataspaces within the domain. For example, if you want to assign the Admin entitlement for dataspaces DS1, DS2, and DS3 to a user, then select the Admin entitlement option. Similarly, you can assign, monitor and browser entitlements to a user for all dataspaces by selecting the Monitor or Browser option from the navigation tree.

    Note:

    In this case, the Admin entitlement is selected for the dataspace DS1.

  4. Click Add Conditions on the Policy tab.

  5. Select the predicate as User and click Next.

    You can also select other options from the list of predicates. For more information, refer to Section 5.2, "Understanding Runtime Security Policies."

  6. Specify the user name for which you want to assign the admin entitlement and click Finish. This creates a user who has Admin entitlement for dataspace DS1.

A user views the category-list based on the entitlement assigned to that user for that dataspace. For example, User A with admin entitlement for DS1 can view the Security Configurations tab, however, if User A has monitor entitlement for DS2, then the Security Configuration tab for DS2 will not appear for User A.

5.6.1.1 Gaining Administrative Access After a System Lockout

Security policies configured for assigning Admin entitlement to a user may get deleted inadvertently. If that is the only Admin user entitlement for Oracle Data Service Integrator Administration Console, then the Admin user is locked out of the console.

In this case, you can configure the com.bea.dsp.security.admin.bootstrap system property for WebLogic Server. This property allows you to specify a user name, who gains domain access rights. However, this property should only be used if the Oracle Data Service Integrator Administration Console is locked due to some policy editing.

To configure this system property:

  1. Stop WebLogic Server.

  2. Open the setDomainEnv.cmd file located in: <BEA_HOME>\user_projects\domains\base_domain\bin

  3. Edit this file to include the com.bea.dsp.security.admin.bootstrap system property. For example:

    set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES%
   -Dwlw.iterativeDev=%iterativeDevFlag%
   -Dwlw.testConsole=%testConsoleFlag%
   -Dwlw.logErrorsToConsole=%logErrorsToConsoleFlag%
   -Dcom.bea.dsp.security.admin.bootstrap=<username>

    where <username> is the place to specify the Admin user for Oracle Data Service Integrator Administration Console.

    Note:

    The user name specified in the com.bea.dsp.security.admin.bootstrap system property should be a user that has already been created using the WebLogic Server Administration Console.

  4. Save and close this file.

  5. Restart WebLogic Server.

  6. Log in to Oracle Data Service Integrator Administration Console using this user name and then re-configure the Admin entitlement policies.

5.6.2 Taking Lock and Edit Capability

A domain user can take back the control of the lock from Oracle Data Service Integrator Administration Console. The lock may need to be taken back from a user in cases where a user, such as an admin user, has acquired the lock but has not released it for a long period and another admin user needs to acquire the lock to modify configurations. One domain user can acquire the lock from another domain user also.

When lock is acquired by a user, the Take Lock & Edit option is enabled for the domain user as shown in Figure 5-23.

Figure 5-23 Take Lock & Edit Enabled in the Change Center

Description of Figure 5-23 follows
Description of ''Figure 5-23 Take Lock & Edit Enabled in the Change Center''

The domain user can click the Take Lock & Edit option from the change center to acquire the lock. In this case, the user whose lock is acquired will see the core configuration values on the console and the domain user or the other admin user will be able to view all the changes made by the other user using the pending changelist. For more information about pending changelist, refer to Section 2.3.1.2, "Pending Changelist."