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:
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.
Integration with ODSI supports the following use-case scenario:
The document assumes the following:
WLESarme.properties
as described in those chapters.set-wls-env.bat|sh
and restart the server:
On Windows: set WLES_JAVA_OPTIONS=%WLES_JAVA_OPTIONS% -Dales.dbAtnProvider.addDirectoryPrincipal=false
On UNIX:WLES_JAVA_OPTIONS=
"$WLES_JAVA_OPTIONS -Dales.dbAtnProvider.addDirectoryPrincipal=false
”
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. |
security.properties
that specifies the ODSI security realm and copy it to the domain directory. The file should contain the following two entries:
wles.realm=<aldsprealm>
wles.default.realm=<aldsprealm>
where <aldsprealm>
is the name of the security realm.
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. |
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:
http://<hostname>:<port>/dspconsole
. Then log in as an administrator.
To create the Identity directory and users:
aldspusers
) and click OK. LDSampleUsers
) and click OK. LDSampleUsers
group:
Jack
(password: weblogic)—RTLApp userSteve
(password: weblogic)—RTLApp userTim
(password: weblogic)—RTLApp userweblogic
(password: weblogic)—ldconsole administrator
This section describes how to use the OES Administration Console to define the RTLApp and ODSI resources to be protected by OES.
To create RTLApp application resources, perform the following steps:
aldsprealm
as the name, select Binding in the Type field, and click Ok.aldsprealm
resource and click Configure. 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
This section describes how to create the Authorization and Role Mapping policies to protect the ODSI 3.2 sample application.
Define the Authorization policies shown in Table 5-1.
Define the role policies shown in Table 5-2.
After defining the identities, resources, and policies to secure the ODSI data service(s), deploy the results as follows:
After this, you can test access to RTLApp using the following steps:
<odsi_home>\samples\domains\aldsp
directory and running startWebLogicALES.cmd|sh
.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).
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:
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 replacement function is called instead of the original user-requested function. For example, if a user requests a call to the getOrders
function and authorization is granted, the getOrdersThatAmountLessThan1000
replacement function is returned to ODSI and is called to return a lesser result than the original.
The returned information is the name of a XQuery Expression that is applied to the invoked function or its replacement, as a predicate. Multiple predicates may be returned and applied to the function.
For example, if a user request calls the getOrders
function and authorization is granted, OES returns “./order/amount < 1000
” as a predicate. This expression is applied to the getOrders
function so that only a subset of orders will be returned to the user.
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.
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.
This attribute provides the name of an ODSI replacement function that ODSI calls instead of the original one. The function name should be fully-qualified, including the namespace:
report_as(
"aldsp_replacement_function
",
"{ld:RetailApplication/OrderManagement/OrderService}:getOpenOrdersByCustID
")
This attribute defines an XQuery expression that will be used as a filter in ODSI. For example:
if report_as(“aldsp_xquery_expression”, “./order/amount < 1000”)
The attribute value can be a list. If so, ODSI applies the AND operator to the list values.
This attribute defines the namespace mapping for prefixes and is used in XQuery expressions. For example:
report_as(“aldsp_namespace_binding”, “f1=http://com.bea.security”) and report_as(“aldsp_xquery_expression”, “./f1:region eq 'west'”)
For “f1=http://com.bea.security”
to be usable, the namespace map should contain the entry that maps the string prefix (f1
) to the namespace (http://com.bea.security
).
Additional tasks are required implement pre-processing data redaction.
Modify set-wls-env.bat|sh
in the WLS SSM instance directory. To do this:
set-wls-env.bat|sh
in an editor. ldintegration.jar
to the end of WLES_POST_CLASSPATH
environment variable.-Dcom.bea.ld.security.FunctionAccessQuery=com.bea.security.ales.aldsp.ALESFunctionAccessProvider
to WLES_JAVA_OPTIONS
.
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
.
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")
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. |
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 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:
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.
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. |
The two OES Java methods are contained in com.bea.security.ales.aldsp.AccessController
class.
public static boolean is_access_allowed(String resource, String[] attributeNames, String[] attributeValues)
public static String[] is_access_allowed_with_response_attributes (String resource, String[] attributeNames, String[] attributeValues)
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
For example, assume that the second parameter contains the array an1,an2
and the third parameter contains the array av1, av2
. This indicates two attributes. The first attribute’s name is an1
and its value is av1
. The second attribute’s name is an2
and its value is av2
.
These attributes and values are then evaluated in the context of the OES policy.
Note: | If the data type of the attribute value is not string, convert it to string via fn:string(). |
In addition, OES attributes support only integer numbers. If the attribute value is a decimal number, truncate it by using fn:round()
before converting to string
.
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:
true
or false
. true’, ‘ALESResponse’, ‘ran1’, ‘rav1_1’, ‘rav1_2’, ‘ALESResponse’, ‘ran2’, ‘rav2’
), where:
— true
is the access permission.— ALESResponse
is a response attribute separator.— ran1
and ran2
are response attribute names. — rav1_1
and rav1_2
are the value of response attribute ran1
. —
the response attribute ran1
is a list value.— rav2
is the value of response attribute ran2
. —
the response attribute ran2
is a single value.
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. |
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:
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.
Use Workshop to add a security XQuery function, as follows:
The OES Java method is an XFL function. The XQuery Function Library (XFL) is a facility for providing auxiliary functions across multiple data services.
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.
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:
alesxfl.jar
and api.jar
from the WLS SSM lib
directory to the ODSI application’s DSP-INF/lib
directory.alesxfl.jar
and select the class com.bea.security.ales.aldsp.AccessController.class
.is_access_allowed
or is_access_allowed_with_response_attributes
, and finish the wizard.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.
ld:Physical/ALES_ACCESS_CONTROL
for namespace and secureOrders
for local name.
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:
datacontrol
and orderview
under the RTLApp
resource, as shown in Figure 5-10.totalorderamount
whose type is integer.
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").
alesxfl.jar
and api.jar
from the WLS SSM lib
directory to the ODSI application’s DSP-INF/lib
directory.Java
Function
as the Data Source Type and click Next. alesxfl.jar
. Then select the class com.bea.security.ales.aldsp.AccessController.class
.is_access_allowed_with_response_attributes
method and click Next.ALES_ACCESS_CONTROL
for the new data service name and finish the wizard. The following bullet points explain the function shown in the figure:
ld:RetailApplication/ALES_ACCESS_CONTROL
for the namespace. Then enter secureOrders
for local name and click Add.http://localhost:7001/RTLSelfService
) and select the user Steve to log on.