|
|
This section provides information about securing ALDSP 2.5 and ALDSP 3.0 data services. It includes the following topics:
ALES can be used to manage access control to entire ALDSP data services or specific data service elements. In addition to simply returning an authorization decision that grants or prevents access, ALES policies can return information to ALDSP 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 ALES components can be integrated with ALDSP.
Integration with ALDSP supports the following use-case scenario:
The document assumes the following:
NOTE: Depending on the ALDSP version, you may have to obtain a patch from BEA support so that ALDSP works correctly with ALES 2.6 and ALES 3.0:
NOTE: Be sure to make the necessary changes to WLESarme.properties as described in those chapters.
The major integration tasks are:
| Note: | In addition to the steps below, additional 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 ALDSP 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 ALES providers for securing ALDSP data services.
Access control must be set on the data service elements to be secured so that ALES 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 ALES:
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 ALES Administration Console to define the RTLApp and ALDSP resources to be protected by ALES.
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 ALDSP resource tree with all nodes expanded except the RTLApp node. For ALDSP 2.5, you must create the resources shown in both Figure 5-2 and Figure 5-3.
Figure 5-4 shows the ALDSP resource tree with all nodes expanded except the RTLApp node. You must create the resources shown in both Figure 5-4 and Figure 5-5.
Because the sample applications provided with ALDSP 2.5 and ALDSP 3.0 are different, they require different policies. These are documented in the following sections:
The Authorization and Role Mapping policies needed to the secure the ALDSP 2.5 sample application are described below.
The following policies allow the Admin role to boot WebLogic Server and perform administrative tasks:
grant(any, //app/policy/aldsprealm/shared/svr, //role/Admin) if true;
grant(any, //app/policy/aldsprealm/shared/adm, //role/Admin) if true;
grant(any, [//app/policy/ aldsprealm /RTLApp/ejb,//app/policy/aldsprealm/RTLApp/ld,//app/policy/aldsprealm/RTLApp/url/rtlselfservice/pages], [//role/Admin]) if true;
grant(any, [//app/policy aldsprealm /RTLApp/ejb/RTLApp_ejb.jar/Metadata,//app/policy/aldsprealm/RTLApp/ejb/RTLApp_ejb.jar], [//role/Admin]) if true;
grant([any,//priv/create], //app/policy/ aldsprealm /RTLApp/ejb/.workshop, //role/Admin) if true;
grant(any, [//app/policy/ aldsprealm /console,//app/policy/aldsprealm/shared/svr,//app/policy/aldsprealm/shared/adm], //role/Admin) if true;
The following policy gives Admin user full access to the LD console.
grant(//priv/any, //app/policy/aldsprealm/ldconsole/url/ldconsole, //role/Admin) if true;
Perform the following steps to create the Authorization policies shown above.
| Note: | If a policy specifies multiple resources for a single privilege and role, you may specify these resources in one policy. |
The following policy assigns the Everyone role to all users in the aldsprealm directory.
grant(//role/Everyone, //app/policy/aldsprealm, //sgrp/aldspusers/allusers/) if true;
The following policy assigns the weblogic user to the Admin role within aldsprealm.
grant(//role/Admin, //app/policy/aldsprealm, //user/aldspusers/weblogic/) if true;
To create the Role Mapping policies above, perform the following steps.
aldsprealm and click Add.allusers in the Roles list and click Add.This section describes how to create the Authorization and Role Mapping policies to protect the ALDSP 3.0 sample application.
Define the Authorization policies shown in Table 5-1:
Define the Authorization policies shown in Table 5-2:
After defining the identities, resources, and policies to secure the ALDSP data service(s), deploy the results as follows:
After this, you can test access to RTLApp using the following steps:
Note: These steps may vary slightly depending on the ALDSP version being used.
<bea_home>\<weblogic_home>\samples\domains\ldplatform directory and running startWebLogicALES.cmd (Windows) or startWeblogicALES.sh (UNIX).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-6).
Pre-processing data redaction involves modifying the client request in some way before ALDSP forwards the request to the data service. This is achieved through the use of an ALES plug-in that calls the Java API to authorize the user request, gets the response attributes from the authorization response, and returns them to ALDSP.
Here is the sequence of events that occur during pre-processing redaction:
ALES supports two types of responses that return information to ALDSP 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 ALDSP 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, ALES 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 ALES plug-in (com.bea.security.ales.aldsp.ALESFunctionAccessProvider) calls the Java SSM to do authorization and return response attributes to ALDSP. For example, consider the following policy:
grant (
//priv/ALDSP_QUERY, //app/policy/RTLApp/ld/DataServices/RTLServices/OrderView.ds/getOrders,
//user/asi/system/
) if report_as(“aldsp_replacement_function”, “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. ALDSP 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 ALES response attributes must be used to return replacement functions or XQuery expressions. They must be returned by the ALES evaluation functions report and report_as or by user-defined evaluation functions.
ALES response attribute names are all lower case.
This attribute provides the name of an ALDSP replacement function that ALDSP calls instead of the original one. The function name should be fully-qualified, including the namespace:
report_as("aldsp_replacement_function", "ld:DataServices/RTLServices/OrderView:getOpenOrdersByCustID")
This attribute defines an XQuery expression that will be used as a filter in ALDSP. For example:
if report_as(“aldsp_xquery_expression”, “./order/amount < 1000”)
The attribute value can be a list. If so, ALDSP 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 in the WLS SSM instance directory. To do this:
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,//RTLApp/DataServices/RTLServices/OrderView.ds/
getOrders,//role/Admin/)if report_as(“aldsp_replacement_function”,
“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 (00”)
//priv/ALDSP_QUERY,
//app/policy/RTLApp/ld/DataServices/RTLServices/OrderView.ds/getOrders,//user/asi/anonymous/
) if report_as(“aldsp_xquery_expression”, “./ns1:order/amount < 10
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 (ty”)
//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.securi
Post-processing data redaction is achieved by invoking a security XQuery function after the ALDSP 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 ALDSP 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.
ALES provides two ALES 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 ALES Java methods can be used instead of, or in addition to, the following ALDSP access control function extensions:
For example, in the XQuery function shown below, fn-bea:is-access-allowed could be replaced with one of the ALES 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 ALDSP console, because the console compiler does not access the custom functions used in it. |
The two ALES 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 ALES policy.
| Note: | If the data type of the attribute value is not string, convert it to string via fn:string(). |
In addition, ALES 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-11:
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 ALES Java method is an XFL function. The XQuery Function Library (XFL) is a facility for providing auxiliary functions across multiple data services.
If ALES 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 ALES Java function.
The ALES 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 ALES Java methods into the ALDSP security XQuery function, you must configure the WLS SSM to protect the ALDSP 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 ALDSP application’s APP-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 ALES. 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 ALES Security XQuery Function (ALDSP 3.0).
<ALDSP_APPLICATION_NAME> LDConfig.xml in <ALDSP_DOMAIN>/liquiddata. <con:AdminResources>, such as the following:<con:AdminResources>
<con:AdminResource>
<con:xpath>SecuredElementName</con:xpath>
<con:useTag>false</con:useTag>
</con:AdminResource>
<con:AdminResource>
<con:xpath> SecuredElementName</con:xpath>
<con:QueryRef>SecurityXQueryFunctionName</con:QueryRef>
<con:useTag>false</con:useTag>
</con:AdminResource>
</con:AdminResources>
SecuredElementName is the XPath of the secured data element and SecurityXQueryFunctionName is the custom security XQuery function name.
| Note: | An example for ALDSP 3.0 is provided in ALES Security XQuery Function (ALDSP 3.0). |
In this example, based on the RTLApp that is shipped by ALDSP 2.5, 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 ALDSP 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-12.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 ALDSP application’s APP-INF/lib directory.alesxfl.jar and select the class com.bea.security.ales.aldsp.AccessController.class.is_access_allowed_with_response_attributes method and finish the wizard.library.xfl, as shown in Figure 5-14. The following bullet points explain the function shown in the figure:OrderView.secureOrders.totalorderamount, which was defined in Step 1.c. The third parameter is a string array that contains attribute values. TotalOrderAmount is xsd:decimal. The function fn:round() converts the element into a integer. The function fn:string() converts the element into a string.true, it indicates that the current operation is permitted. class, which was defined in Step 1.d. class is not found, return false. class contains the value A.RTLAppLDConfig.xml in BEA_HOME/weblogic81/samples/domains/ldplatform/liquiddata.
<con:DSConfiguration id="ld:DataServices/RTLServices/OrderView.ds">
<con:DSConfiguration> element:
<con:AdminResources>
<con:AdminResource>
<con:xpath>ORDER</con:xpath>
<con:useTag>false</con:useTag>
</con:AdminResource>
<con:AdminResource>
<con:xpath>ORDER</con:xpath>
<con:QueryRef>{lib:DataServices/library}secureOrders
</con:QueryRef>
<con:useTag>false</con:useTag>
</con:AdminResource>
</con:AdminResources>
When the Status of Last Action is Success, the application has been redeployed.
Steve to log in, as shown in Figure 5-15.| Note: | An example for ALDSP 2.5 is provided in ALES Security XQuery Function (ALDSP 2.5). |
In this example, based on the RTLApp that is shipped by ALDSP 3.0, 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 ALDSP 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-17.
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 ALDSP application’s APP-INF/lib directory.
Java Function as the Data Source Type and click Next. alesxfl.jar and 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.
|
