Integration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Securing Oracle Data Service Integrator

This section provides information about securing Oracle Data Service Integrator (ODSI) 3.2, formerly known as AquaLogic Data Services Platform (ALDSP). It includes the following topics:

 


Overview

OES can be used to manage access control to entire ODSI data services or specific data service elements. In addition to simply returning an authorization decision that grants or prevents access, OES policies can return information to ODSI for use when performing pre- or post-processing data redaction. As a result, the user receives a redaction of the data requested.

For information about policies used for data redaction, see Pre-Processing Data Redaction and Post-Processing Data Redaction.

The following diagram illustrates how OES components can be integrated with ODSI.

Figure 5-1 ODSI Integration Overview

ODSI Integration Overview

 


Use-Case

Integration with ODSI supports the following use-case scenario:

 


Prerequisites

The document assumes the following:

 


Integration Tasks

The major integration tasks are:

Note: In addition to the steps below, other tasks are required to define policies for data redaction. For pre-processing data redaction, see Pre-Processing Data Redaction. For post-processing data redaction, see Post-Processing Data Redaction.
  1. Create the startWebLogic.cmd file for the ODSI domain as described in the SSM Installation and Configuration Guide.
  2. Create a file named security.properties that specifies the ODSI security realm and copy it to the domain directory. The file should contain the following two entries:
  3. wles.realm=<aldsprealm>
    wles.default.realm=<aldsprealm>

    where <aldsprealm> is the name of the security realm.

  4. Define the security providers as described in Define Security Providers.
  5. In ODSI, enable security on the data service elements to be secured as described in Enable ODSI Elements for Access Control.
  6. Define ODSI identities in OES. For instructions using the RTLApp sample application, see Define ODSI Identities in OES.
  7. Define ODSI resources in OES. This chapter provides instructions for resources that represent RTLApp resources. See Define ODSI Resources in OES.
  8. Define the Authorization and Role Mapping policies that secure RTLApp as described on Define Policies for ODSI.
  9. Distribute the policies to the SSM by following the instructions in Distribute Policies.

 


Define Security Providers

The following table provides information about OES providers for securing ODSI data services.

Note: Before creating these providers in OES, use the WebLogic console to define a new security realm and add some providers to this realm.

Provider
Configuration Settings
ASI Adjudication Provider
Use the defaults for all settings.
Log4j Auditor
Use the defaults for all settings.
Database Authentication
Set the Control Flag to SUFFICIENT and the Identity Scope to aldspusers. Use the defaults for all other settings.
ASI Authorization
Set the Identity Scope to aldspusers. Use the defaults for all other settings.
WebLogic Credential Mapper
Deselect the Credential Mapping Deployment Enabled checkbox.
ASI Role Mapping
Set the Identity Scope to aldspusers. Use the defaults for all other settings.

 


Enable ODSI Elements for Access Control

Access control must be set on the data service elements to be secured so that OES is invoked to determine if access to the data should be granted. The following steps describe how to enable security on RTLApp data service elements to be secure with OES:

  1. Open a browser and go to http://<hostname>:<port>/dspconsole. Then log in as an administrator.
  2. Select Lock & Edit to enable editing.
  3. Specify the dataspace to be controlled by OES:
    1. Select the RetailDataspace and click the Security Configuration tab.
    2. On the General tab, select Enable Access Control and Enable JDBC Metadata Access Control. Then click Save.
  4. Specify the data services elements to be controlled by OES:
    1. Expand RetailDataspace > RetailApplication > CustomerManagement > CustomerService and select the Security Configuration tab.
    2. Select the Secured Elements tab. Then select CUSTOMER/ORDERS/ORDER_SUMMARY/OrderDate as an element to be secured. (This allows the element call to go to the security check.)
    3. Expand RetailDataspace > RetailApplication > CustomerManagement > CustomerService and click CUSTOMER/ORDERS/ORDER_SUMMARY/OrderDate.
    4. Select Secured Elements Configuration.
    5. Select Remove and click Save to save the changes.
    6. Click Activate Changes.

 


Define ODSI Identities in OES

To create the Identity directory and users:

  1. In the OES Administration Console’s left pane, select the Identity node and click New at the bottom of the right pane.
  2. On the Create Directory dialog, enter the directory name (for example, aldspusers) and click OK.
  3. Under the Identity node, select Groups and click New at the bottom of the right pane.
  4. On the Create Group dialog, enter the group name (for example, LDSampleUsers) and click OK.
  5. Under the Identity node, create the following users and add them to the LDSampleUsers group:
  6. Jack (password: weblogic)—RTLApp user
    Steve (password: weblogic)—RTLApp user
    Tim (password: weblogic)—RTLApp user
    weblogic (password: weblogic)—ldconsole administrator

 


Define ODSI Resources in OES

This section describes how to use the OES Administration Console to define the RTLApp and ODSI resources to be protected by OES.

RTLApp Application Resources

To create RTLApp application resources, perform the following steps:

  1. Expand the Resources node and select Resources.
  2. In the right pane, select Policy and click New.
  3. On the Create Resource dialog, enter aldsprealm as the name, select Binding in the Type field, and click Ok.
  4. Select the aldsprealm resource and click Configure.
  5. On the Configure Resource dialog, select Binding Application in the Type field, select the Distribution Point checkbox and click Ok.
  6. Modify the ASI Authorization and ASI Role Mapper providers as follows:
    • Set the Application Deployment Parent to //app/policy/aldsprealm
    • On the Bindings tab, bind to //app/policy/aldsprealm

ODSI Resources

Figure 5-2 shows the ODSI resource tree with all nodes expanded except the RTLApp node. You must create the resources shown in both Figure 5-2 and Figure 5-3.

When defining the resources, make sure the following resources are defined as “virtual resources”:

— //app/policy/aldsprealm/consoleapp
— //app/policy/aldsprealm/dspconsole
— //app/policy/aldsprealm/ElectronicsWS/ld
— //app/policy/aldsprealm/RetailDataspace/ld
— //app/policy/aldsprealm/RTLApp/url
— //app/policy/aldsprealm/shared

Figure 5-2 ODSI Resource Tree with RTLApp Node Collapsed

ODSI Resource Tree with RTLApp Node Collapsed

Figure 5-3 ODSI Resource Tree with RTLApp Node Expanded

ODSI Resource Tree with RTLApp Node Expanded

 


Define Policies for ODSI

This section describes how to create the Authorization and Role Mapping policies to protect the ODSI 3.2 sample application.

Authorization Policies

Define the Authorization policies shown in Table 5-1.

Table 5-1 Authorization Policies for ODSI 3.2
Policies
Description
grant( any, [//app/policy/aldsprealm/shared/adm,//app/policy/aldsprealm/shared/svr], //role/Admin) if true;
grant( any, //app/policy/aldsprealm/WseeJmsModule, //role/Admin) if true;
grant( any, //app/policy/aldsprealm/shared, //role/Admin) if true;
Grants Admin Role and/or weblogic user permission to boot WLS and perform administrative tasks.
grant( any, //app/policy/aldsprealm/dspconsole, //role/Admin/) if true;
grant( [//priv/GET,//priv/POST], //app/policy/aldsprealm/dspconsole/url/dspconsole, //role/Everyone) if true;
Gives WebLogic full access to the DSP console.
grant( [//priv/GET,//priv/POST], //app/policy/aldsprealm/consoleapp/url/console/login, //role/Everyone) if true;
grant( //priv/receive, //app/policy/aldsprealm/WseeJmsModule/jms/queue/WseeMessageQueue, //role/Everyone) if true;
grant( //priv/reserve, //app/policy/aldsprealm/shared/jdbc, //role/Everyone) if true;
grant( //priv/lookup, [//app/policy/aldsprealm/shared/jdbc,//app/policy/aldsprealm/shared/jndi], //role/Everyone) if true;
grant( //priv/read, //app/policy/aldsprealm/shared/workcontext, //role/Everyone) if true;
grant( //priv/lookup, //app/policy/aldsprealm/shared/jms, //role/Everyone) if true;
grant( //priv/send, //app/policy/aldsprealm/shared/jms, //role/Everyone) if true;
Grants Everyone role (including the anonymous user) access all of the shared open resources.
grant( any, //app/policy/aldsprealm/RTLApp/url, [//sgrp/aldspusers/LDSampleUsers/, //role/Admin]) if true;
Allows all users to access the sample application.
grant( any, //app/policy/aldsprealm/shared/ld, //role/Everyone) if true;
grant( any, [//app/policy/aldsprealm/shared/svr,//app/policy/aldsprealm/shared/adm,//app/policy/aldsprealm/consoleapp], //role/Everyone) if true;
grant( any, //app/policy/aldsprealm/ElectronicsWS/ld, //app/policy/aldsprealm/RetailDataspace/ld [//role/Admin,//sgrp/aldspusers/LDSampleUsers/]) if true;
Grants permission for data services.
Deny( any, //app/policy/aldsprealm/RetailDataspace/ld/RetailApplication/CustomerManagement/CustomerService.ds/CUSTOMER/ORDERS/ORDER_SUMMARY/OrderDate, //user/aldspusers/Steve/) if true;
Deny the Steve user to access the dataservice element.

Role Policies

Define the role policies shown in Table 5-2.

Table 5-2 Role Mapping Policies for ODSI 3.2 Sample Application
Policies
Description
grant(//role/Everyone, //app/policy/aldsprealm, //sgrp/aldspusers/allusers/) if true;
Allows Everyone role to be used in aldsprealm Identity directory.
grant(//role/Admin, //app/policy/aldsprealm, //user/aldspusers/weblogic/) if true;
Grants the weblogic user Admin role within aldsp realm.

 


Distribute Policies

After defining the identities, resources, and policies to secure the ODSI data service(s), deploy the results as follows:

  1. In the OES Administration Console’s left pane, select the Deployment node.
  2. On the Policy tab in the right pane, select the checkbox before the name of the ODSI resource parent and click Distribute Policy.
  3. If you made any changes to the SSM configuration used to secure the ODSI domain, display the Configuration tab and select the checkbox for the SSM configuration. Then click Distribute Configuration Changes.

After this, you can test access to RTLApp using the following steps:

  1. Start a WebLogic Server instance by changing to the <odsi_home>\samples\domains\aldsp directory and running startWebLogicALES.cmd|sh.
  2. Access the RTLApp by pointing a browser to http://<hostname>:<port>/RTLSelfService where <hostname> is the machine on which RTL application is running. The browser is redirected to the authentication page (see Figure 5-4).
  3. Figure 5-4 Authentication Page


    Authentication Page

  4. Log in as Steve and access should be granted to the Profile Page (see Figure 5-5).
  5. Figure 5-5 Profile Page


    Profile Page

  6. Select Open Orders Page. Open orders should be visible (see Figure 5-6), while access to Order Data should be denied.
  7. Figure 5-6 Open Orders Page


    Open Orders Page


    Open Orders Page

 


Pre-Processing Data Redaction

Pre-processing data redaction involves modifying the client request in some way before ODSI forwards the request to the data service. This is achieved through the use of an OES plug-in that calls the Java API to authorize the user request, gets the response attributes from the authorization response, and returns them to ODSI.

Here is the sequence of events that occur during pre-processing redaction:

  1. ODSI receives a data service client request and invokes the OES plug-in.
  2. OES plug-in calls the OES Java API for authorization. The authorization decision returns additional predicates as responses.
  3. OES plug-in returns the authorization decision and responses to ODSI.
  4. ODSI adds the predicates and/or function name and calls the data service
  5. ODSI engine receives the results from the data service and returns it to the client.
  6. Figure 5-7 Overview of Pre-Processing Solution


    Overview of Pre-Processing Solution

Pre-Processing Response Types

OES supports two types of responses that return information to ODSI in the form of security predicates. They can be used separately or together.

The OES plug-in (com.bea.security.ales.aldsp.ALESFunctionAccessProvider) calls the Java SSM to do authorization and return response attributes to ODSI. For example, consider the following policy:

grant (
//priv/ALDSP_QUERY, //app/policy/aldsprealm/RetailDataspace/ld/RetailApplication/OrderManagement/getOrderByCustID,
//user/aldspusers/Steve/


) if report_as(“aldsp_replacement_function”, “{ld:RetailApplication/OrderManagement/OrderService}getOrdersThatAmountLessThan1000”)

This policy grants the system user the ALDSP_QUERY privilege on the OrderView data service’s getOrders function. If the authorization decision is true, it returns the aldsp_replacement_function attribute with a value of getOrdersThatAmountLessThan1000. ODSI then calls that replacement function (instead of the original). This function must the same signature; no additional verifications are performed at runtime.

Required OES Response Attributes

One of three OES response attributes must be used to return replacement functions or XQuery expressions. They must be returned by the OES evaluation functions report and report_as or by user-defined evaluation functions.

OES response attribute names are all lower case.

Additional Integration Tasks

Additional tasks are required implement pre-processing data redaction.

Modify the Start WebLogic Script

Modify set-wls-env.bat|sh in the WLS SSM instance directory. To do this:

  1. Navigate to the WLS SSM instance directory and open set-wls-env.bat|sh in an editor.
  2. Add ldintegration.jar to the end of WLES_POST_CLASSPATH environment variable.
  3. Add the JVM option -Dcom.bea.ld.security.FunctionAccessQuery=com.bea.security.ales.aldsp.ALESFunctionAccessProvider to WLES_JAVA_OPTIONS.

Write Replacement Functions

Replacement functions must be implemented on the target data service and have the same return type and number/type of parameters as the function being replaced. For example, to restrict OrderView.getOrders to return only orders totalling less than $1000.00, write an XQuery function to implement the restriction. This function must have the same return type, and number types of parameters as getOrders.

Define Policies for Replacement Functions

To use a replacement function to protect data services, define a policy that allows access to the target data service’s function and returns the aldsp_replacement_function attribute with the name of the replacement function. There are no additional access control checks performed for the replaced function.

Note: All policies for pre-processing data redaction must use the ALDSP_QUERY privilege.

For example, the following policy returns a replacement function named getOrdersThatAmountLessThan100:

grant (
//priv/ALDSP_QUERY, //app/policy/aldsprealm/RetailDataspace/ld/RetailApplication/OrderManagement/getOrderByCustID,
//user/aldspusers/Steve/

) if report_as("aldsp_replacement_function", "{ld:RetailApplication/OrderManagement/OrderService}getOrdersThatAmountLessThan1000")

Define Policies for XQuery Expressions

To use an XQuery expression, define a policy that returns aldsp_xquery_expression and the name of an XQuery expression. For example:

grant(//priv/ALDSP_QUERY,//RTLApp/ld/DataServices/RTLServices/OrderView.ds
/getOrders,//user/asi/anonymous/)if report_as(“aldsp_xquery_expression”,
“./order/amount < 1000”)
Note: All policies for pre-processing data redaction must use the ALDSP_QUERY privilege.

Define Namespace Bindings

You must define namespace binding used in an XQuery expression. (Namespace bindings are not used for replacement function names; they must be fully qualified, including the namespace.) For example, consider the following policy:

grant (
//priv/ALDSP_QUERY,
//app/policy/RTLApp/ld/DataServices/RTLServices/OrderView.ds/getOrders,//user/asi/anonymous/
) if report_as(
aldsp_xquery_expression”, “./ns1:order/amount < 1000”)

In this case, you need to define the mapping of namespace ns1 and return it. Therefore, you need to add another response attribute, as follows:

grant (
//priv/ALDSP_QUERY,
//app/policy/RTLApp/ld/DataServices/RTLServices/OrderView.ds/getOrders,
//user/asi/anonymous/
) if report_as(
aldsp_xquery_expression, ./ns1:order/amount < 1000”) and report_as(“aldsp_namespace_binding”, “ns1=http://com.bea.security)

 


Post-Processing Data Redaction

Post-processing data redaction is achieved by invoking a security XQuery function after the ODSI engine retrieves the data from the data service. The XQuery function determines whether to grant access and return the data. Note: This approach may not be suitable for fast operations or very large data sets.

Here is the sequence of events that occur during post-processing redaction:

  1. Client sends a data retrieving request to ODSI.
  2. ODSI engine retrieves the data from the data service(s).
  3. ODSI invokes the relevant security XQuery function for the data element.
  4. Security XQuery function invokes an OES Java method, passing in the resource name and one or more attribute names/values.
  5. OES Java method invokes the WLS SSM and gets the authorization result and optional responses defined in the queries.
  6. OES Java method returns the authorization decision and a set of responses to the security XQuery function.
  7. XQuery function may use the OES-supplied responses to make the decision. For example, the policy decision may evaluate as true, but based on the responses the function may return false.
  8. Figure 5-8 Overview of the Post-Processing Solution


    Overview of the Post-Processing Solution

ODSI Security XQuery Functions

The ODSI security XQuery functions enable you to specify custom security policies that can be applied to data elements. The functions are useful for creating policies based on data values. For example, to deny access to an element if the order amount exceeds a given threshold.

OES provides two Java methods that can be called by security XQuery functions. These methods invoke the WLS SSM which determines whether the access request should be granted.

The OES Java methods can be used instead of, or in addition to, the following ODSI access control function extensions:

For example, in the XQuery function shown below, fn-bea:is-access-allowed could be replaced with one of the OES Java method.

Listing 5-1 Example Security XQuery Function

declare namespace demo="demo";
declare namespace retailerType="urn:retailerType";

declare function demo:secureOrders($order as element(retailerType:ORDER_SUMMARY) ) as xs:boolean {
if (fn-bea:is-access-allowed("LimitAccess",
"ld:DataServices/RTLServices/OrderSummaryView.ds")) then
fn:true()
:
:

Note: Because the security XQuery function depends on the data service schema. You must create the security XQuery function based on the custom data service schema.
Note: Custom security XQuery functions must be created in Workshop, instead of the ODSI console, because the console compiler does not access the custom functions used in it.

OES Java Methods

The two OES Java methods are contained in com.bea.security.ales.aldsp.AccessController class.

Parameters

These methods have three parameters as shown in the following example:

let $result := f1:is_access_allowed_with_response_attributes
              ("RTLApp/datacontrol/orderview",
              ("totalorderamount"),
              (fn:string(fn:round ($order/TotalOrderAmount)))) return

Return Values

The is_access_allowed method returns a boolean value (true or false) representing the access permission. You can return this value directly to the security XQuery function or do some additional operation based on the result.

The is_access_allowed_with_response_attributes method returns:

You can test the access permission by comparing the first element of the string array with true or false.

Note: In addition, you can use the response attribute value to implement additional logic, as described below.

Policies Returning Attributes to ODSI

If you use the is_access_allowed_with_response_attributes method, you can create a policy that returns response attributes and then test those attributes.

As described in Using Response Attributes, response attributes are typically specified using built-in evaluation functions that report name/value pairs. There are two functions for returning attributes: report() and report_as(). These functions always return true (if there are no errors), and their information is passed to your application as response attributes embedded within the ResponseContextCollector.

The report_as function allows you to write the policy to specify both the attribute name and value. For example, report_as("class", "A"). The security XQuery function can then test the return response attributes as shown in Figure 5-9:

Figure 5-9 Testing Return Response Attributes

Testing Return Response Attributes

The report_as function loads a named response attribute with a value that specifies an attribute, constant, or a string literal. When returning multiple values, the response attribute is returned as a list.

The report() and report_as()functions are not policy constraints. The attributes are returned only if the authorization decision is true.

Defining a Security XQuery Function

Use Workshop to add a security XQuery function, as follows:

  1. Import the OES Java method via an XFL library in the current Workshop application, as described in Integrating the OES Java Methods.
  2. The OES Java method is an XFL function. The XQuery Function Library (XFL) is a facility for providing auxiliary functions across multiple data services.

  3. To obtain the data service elements, import the namespace of the data service XML schema.
  4. Add an XQuery Function and specify the root element of the data service as the parameter.
  5. In of the XQuery Function, specify all of the attributes that may be returned by the OES policies protecting the resource. Use two string arrays for names and values.
  6. If OES policies for the affected DSP resource require any context parameters to be passed with the request, those parameters should be extracted in the custom XQuery Security function and passed to the SSM via the OES Java function.

    The OES Java method is able to determine the authenticated subject to use for authorization, and you do not need to supply it.

  7. Invoke the OES Java Function with the resource name, attributes, and values.

Integrating the OES Java Methods

Before you can integrate the OES Java methods into the ODSI security XQuery function, you must configure the WLS SSM to protect the ODSI domain, as outlined in Integration Tasks.

After you have done this, then:

  1. Configure and distribute the policy in OES:
    1. Define a resource to indicate the current data element of data service.
    2. Define a policy for the resource. If necessary, declare some attributes, and use them in the policy constraints. These attributes must later be passed into the OES Java method in Step 3.d.
    3. Distribute the policy change.
  2. Import the OES Java method as an XFL library in the current Workshop application:
    1. Copy alesxfl.jar and api.jar from the WLS SSM lib directory to the ODSI application’s DSP-INF/lib directory.
    2. In the ODSI application, right-click the node of the data service project and select Import Source Metadata.
    3. Select Java Function as the Data Source Type and click Next.
    4. Expand alesxfl.jar and select the class com.bea.security.ales.aldsp.AccessController.class.
    5. In the next page, based on your use case, select either is_access_allowed or is_access_allowed_with_response_attributes, and finish the wizard.
  3. Use Workshop to create a security XQuery function in the ODSI application:
    1. Open the XFL file created in Step 2.
    2. Import the namespace of the data service.
    3. Add an XQuery function and define one parameter whose type is the whole data service.
    4. In the XQuery function, supply the OES Java method with the resource name, and the attributes and values you want to test. For example:
    5. let $result := f1:is_access_allowed_with_response_attributes
                    ("RTLApp/datacontrol/orderview",
                    ("totalorderamount"),
                    (fn:string(fn:round ($order/TotalOrderAmount)))) return

      The first parameter is the resource name as defined in OES. The second parameter is a string array that contains attribute names. In the example, there is only one attribute, named totalorderamount. The third parameter is a string array that contains attribute values.

      A detailed example is provided in OES Security XQuery Function.

  4. Specify the data service element to protected:
    1. Log in to the ODSI console.
    2. Click Lock & Edit.
    3. Select Security Configuration on the bottom right.
    4. Select proper secured element from data space navigation tree and add the XQuery security function in right panel, e.g. ld:Physical/ALES_ACCESS_CONTROL for namespace and secureOrders for local name.
    5. Click Activate Changes.
  5. Redeploy the application in the Weblogic Server Administration Console:
    1. Log in to the Weblogic Server Administration Console.
    2. Expand the Deployments | Applications node and select the ALDSP application node.
    3. In right tab, select the Deploy tab.
    4. Click the Redeploy Application button.
    5. When the status is Success, the application has been redeployed.

  6. Restart the WebLogic Server.

OES Security XQuery Function

In this example, based on the RTLApp that is shipped by ODSI 3.2, the data service OrderView is configured with a security XQuery function to protect its data elements. It is assumed that the application RTLApp has been deployed on an ODSI domain that is protected by the WLS SSM.

The integration example follows these steps:

  1. Configure and distribute the policy in OES:
    1. In the OES Administration console, define resources named datacontrol and orderview under the RTLApp resource, as shown in Figure 5-10.
    2. Figure 5-10 ODSI Resource Tree


      ODSI Resource Tree

    3. Define a dynamic attribute named totalorderamount whose type is integer.
    4. Define and distribute the following an authorization policy:
    5. grant( view, //app/policy/aldsprealm/RTLApp/datacontrol/orderview, //sgrp/aldspusers/LDSampleUsers/) IF (totalorderamount < 1000) and report_as (“class”,”A”);

      The privilege is view. The subject is LDSampleUsers. The constraint is totalorderamount < 1000. Response attributes are returned via report_as("class", "A").

  2. Import the OES Java function as an XFL library in the current Workshop application:
    1. Copy alesxfl.jar and api.jar from the WLS SSM lib directory to the ODSI application’s DSP-INF/lib directory.
    2. In the ODSI 3.2 application, right-click RetailDataspace > RetailApplication folder and select New > Physical Data Service, as shown in Figure 5-11.
    3. Figure 5-11 Import OES Java Function


       Import OES Java Function

    4. Select Java Function as the Data Source Type and click Next.
    5. Locate and expand alesxfl.jar. Then select the class com.bea.security.ales.aldsp.AccessController.class.
    6. On the next page, select the is_access_allowed_with_response_attributes method and click Next.
    7. Enter ALES_ACCESS_CONTROL for the new data service name and finish the wizard.
  3. Add a security XQuery function in ALES_ACCESS_CONTROL.ds, as shown in Figure 5-12.
  4. The following bullet points explain the function shown in the figure:

    • Line 36: define a security XQuery function secureOrders.
    • Line 37: invoke the OES Java method. The first parameter is the resource name as defined in OES. The second parameter is a string array that contains attribute names. In the example, there is only one attribute, named totalorderamount. The third parameter is a string array that contains attribute values.
    • Line 39: the TotalOrderAmount element type is xsd:decimal. The fn:round() function converts the element into a integer. The fn:string() function converts the element into a string.
    • Line 40: if the first element is true, it indicates that the current operation is permitted.
    • Line 41: find the response attribute class (defined in step d).
    • Line 42: if the response attribute class is not found, return false.
    • Line 44 to 57: check if the response attribute class contains the value A.
    • Figure 5-12 Security XQuery Function for ODSI 3.2


      Security XQuery Function for ODSI 3.2

  5. Redeploy the dataspace in ODSI Studio:
    1. Navigate to RetailDataspace and select the node.
    2. Navigate to Project at the menu bar and select Clean.
    3. Select RetailDataspace again. Then right-click the dataspace and select Deploy Project.
  6. Specify which element of the data service is protected in the ODSI console:
    1. Login ODSI console and click Lock & Edit.
    2. Select Security Configuration on bottom right and navigate to ALDSP Domain>RetailDataspace>RetailApplication>OrderManagement>OrderService.
    3. On the Secured Elements tab, select the ORDER/ORDER checkbox and click Save.
    4. Navigate to ALDSP Domain > RetailDataspace > RetailApplication> OrderManagement>OrderService>ORDER/ORDER from data space navigation tree and click ORDER/ORDER.
    5. On the Secured Elements Configuration tab, enter ld:RetailApplication/ALES_ACCESS_CONTROL for the namespace. Then enter secureOrders for local name and click Add.
    6. Click Activate Changes.
  7. Open RTLSelfService application (http://localhost:7001/RTLSelfService) and select the user Steve to log on.
  8. Open the Search tab page and click the Search Orders button. Only items less than $1000.00 are displayed as shown in Figure 5-13.
  9. Figure 5-13 Search Results with OES Protection


    Search Results with OES Protection


  Back to Top       Previous  Next