Centralized Security Policy with AquaLogic Enterprise Security: Part 2

by William Dettelback


AquaLogic Enterprise Security (ALES) provides a centralized security policy facility for applications and services. ALES is built on the same core security framework that WebLogic Server and WebLogic Server-based products utilize. This makes it very simple to use ALES as a replacement for the authorization decisions that those products make, and centralizes such security policy into one repository. The benefits of this approach are easier maintenance and lower complexity as the number of authorization decisions are performed across multiple products. Part 1 of this series focused on the WebLogic Portal integration. This part will focus on the integration with AquaLogic Data Services Platform (ALDSP).

Avitek Investments

As a recap from Part 1, Avitek Investments needs to create a WebLogic Portal and AquaLogic Data Services Platform-based solution to serve the needs of different functional roles: Fund Managers, Customers, and Financial Advisors. Because of the sensitive nature of the information, it is important that Avitek enforce strict policies on data and functionality. The specific policies are listed below. We saw in Part 1 how to take care of policies 1, 2, and 4, and now we will examine policies 3 and 5.

  1. Each role gets a differently configured desktop.
  2. Only "high net worth" customers get a Research Page.
  3. Fund managers can see only the funds they are responsible for.
  4. Fund managers in the UK cannot use Fund Operations after 4:00 p.m.
  5. Financial advisors in California cannot view Risk Scores.

AquaLogic Data Services Platform provides a way to easily create services around one or more data sources (for example, databases) using the XQuery language. XQuery is a full-featured programming language, and we could hard-code our security policies directly within the services themselves. For example, we might put in conditional logic to make sure that the resulting Fund information matches the profile of the calling individual (policy 3). Or we might not show a particular element based on some conditional check that, in turn, is based on the caller's state (policy 5). The problem with this solution is that we are mixing security policies with service implementations. Whenever the security policies change, we'll need to modify our ALDSP application. A better solution is to use AquaLogic Enterprise Security to externalize these policies.

AquaLogic Data Services Platform and AquaLogic Enterprise Security have been integrated such that AquaLogic Enterprise Security can intercept a data service and change the query (or result set) without the caller's knowledge. This is important because we can now build very generic, reusable data services. The consumers of these services (for example, our portlets) can just call the services and assume that the data returned is acceptable according to our security policies. ALES works quietly in the middle to enforce those policies without either side needing to have insight into what those policies are. This lets an organization evolve security policies independently from the implementation of the data services themselves.

Configuring the AquaLogic Data Services Platform SSM

Setting up the SSM for ALDSP is similar to the setup for the WebLogic Portal SSM. Since we are using AquaLogic Data Services Platform 2.5 (which is based on WebLogic Server 8.1), we have to add the appropriate providers inside the ALES Administration Console. The specific details can be found here in the product documentation. The resulting configuration is shown in Figure 1.

A Simple Architecture
Figure 1. Security configuration for the aldsprealm in the AquaLogic Enterprise Security Administration Console

Setting Up AquaLogic Data Services Platform Resources in AquaLogic Enterprise Security

ALES can secure ALDSP at both the data-service and element level. In our example, we'll need to apply policies at both levels to satisfy rules 3 and 5, respectively. For rule 3, we need to make sure that a policy is applied to filter out unauthorized fund types based on our fund manager's responsibilities. For rule 5, we'll need to make sure that a policy is applied to remove the Credit Score element for unauthorized users. ALES ships with a set of template resources and policies for bootstrapping an ALDSP domain. The resource tree is shown in Figure 2, and we can see that we have specified resource paths for the FUND data service and CREDIT_RISK_SCORE elements accordingly.

A Simple Architecture
Figure 2. The resource tree for the aldsprealm in the AquaLogic Enterprise Security Administration Console

Configuring Security Access for a Schema Element

Let's take a look at how we would take away the Credit Risk Score from the Brokerage data service. Our Account portlet calls the getAccountDetailsByCustomer() method of the Brokerage data service (Figure 3). Only the authenticated subject is passed to ALDSP from WebLogic Portal; no other information is required.

A Simple Architecture
Figure 3. Brokerage data service

ALDSP has a very straightforward mechanism for marking data elements that need to be secured by the security framework. Inside the ALDSP Administration Console, you simply check the element in the return schema that you need protected (Figure 4).

A Simple Architecture
Figure 4. Protecting the Credit Risk Score element in the ALDSP Administration Console

Now, whenever the Brokerage data service is called, a check will be made via the Authorization Provider to ensure that the authenticated user has appropriate rights to see this element. Since we have replaced the default ALDSP authorization provider with ALES, we'll need to put in some policy to make sure financial advisors from California cannot see the Credit Risk Score (as described by rule 5 above).

deny( any,



    if state = "CA";

ALES will automatically retrieve the value of the state attribute for the subject it was given. As we saw in Part 1, the WebLogic Portal and AquaLogic Data Services Platform domains are configured to use the same identity directory in ALES.

Doing Pre-Query "Narrowing" with AquaLogic Enterprise Security Policy

Restricting access to a schema element is fairly straightforward as we have seen, but it touches on only the surface of what can be done with AquaLogic Enterprise Security and AquaLogic Data Services Platform. There may be situations where security policy needs to "narrow" the results of a data service to ensure that specific rows are not returned to the client. We want the security policy to attach a "where" clause to the query inside the data service prior to execution. AquaLogic Data Services Platform provides a "hook" for AquaLogic Enterprise Security to return back this "where" clause via a specific action called ALDSP_QUERY. The way this works is that, prior to executing the data service, ALDSP will ask whether the user can perform the ALDSP_QUERY action on the data service. If ALES has a grant policy for the ALDSP_QUERY action on this data service method (resource), then ALDSP will look inside the response context for a string containing some XQuery to apply to the data service function.

For example, fund managers get a list of their funds based on type, and this is done in a portlet that uses the Fund data service (Figure 5). As before, the Fund data service is generic and returns a list of all funds available, regardless of type.

A Simple Architecture
Figure 5. Fund data service

Our first step is to segment our fund managers according to the funds they look after. We create the following groups:


We then use the following policies to pass back a small XQuery snippet to ALDSP that restricts the query according to the type our subject is allowed to see:


</p:colorscheme>grant (
//sgrp/aldsp/equity_fund_manager )
if report_as("aldsp_xquery_expression", "./FUND_TYPE = ‘EQTY’");

<p:colorscheme></p:colorscheme>grant (
//sgrp/aldsp/bond_fund_manager )
if report_as("aldsp_xquery_expression", "./FUND_TYPE = ‘BOND’");

<p:colorscheme></p:colorscheme>grant (
//sgrp/aldsp/fx_fund_manager )
if report_as("aldsp_xquery_expression", "./FUND_TYPE = ‘FX’");

This policy uses the report_as feature of ALES to return the XQuery snippet to ALDSP. We refer to this technique as "pre-query narrowing" since the XQuery is inserted into the data service prior to the actual query being performed on the physical data sources. This is important because we might have thousands of fund records that we don't wish to retrieve only to throw most of them away. Also, since we had only a small number of possible values in the FUND_TYPE field, we could hard-code the literal values into our policies (and use groups to segment our users). If we had a larger set of possible values (for example, an account number), a better approach would be to use a custom attribute retriever.

Additional AquaLogic Data Services Platform Use Cases

While not used directly in our example, there are two other cases where AquaLogic Enterprise Security can protect AquaLogic Data Services Platform resources.

Restricting access to a data service

Access to data services in ALDSP can be controlled by an authorization decision in ALES. This is perhaps the most basic use case where we will grant or deny access to a data service based on policy. This is actually the same basic policy that we saw in pre-query narrowing without the additional report_as constraint. For example, if we wanted to make sure customers never have access to the Fund data service:

deny (
//role/Customer );

Post-query redaction

ALES can also be used to perform redaction of schema elements after the query has been performed on the physical data source. ALDSP provides a mechanism to apply an XQuery Security Function to a schema element. These Security Functions are just XQuery functions that can perform conditional processing on the result set of a data service function. For example, we can show only those orders that are under a certain size:

declare function demo:secureOrders($order as element(
retailerType:ORDER_SUMMARY) ) as xs:boolean {
if ($order/TotalOrderAmount
lt (fn-bea:get-property("total_order_amount", "1000000")
cast as xs:decimal)

This is fine for simple situations, however complex policies should be externalized in ALES. As such, ALES provides a way to call out to the SSM inside an XQuery Security Function and take appropriate action:

declare function f1:secureOrders($order as element(ns5:ORDER) )
as xs:boolean {
let $result := f1:is_access_allowed_with_response_attributes(
if ($result[1] eq "true") then
if ($result[2] eq "class" and $result[3] eq "[A]") then
grant( //priv/view,
if totalorderamount < 1000 and report_as("class", "A")

In our policy, we are returning some context (class = "A"), which can then be used conditionally in the XQuery Security Function to perform further decisioning on what ALES returned.


We have seen that AquaLogic Enterprise Security can provide a way to establish common security policy across different tiers in an application—in this case, WebLogic Portal and AquaLogic Data Services Platform. When configured in a WebLogic Portal domain, ALES replaces the default authorizations done for visitor entitlements and intra-portlet security. When configured in an ALDSP domain, ALES provides an elegant mechanism for adding declarative security policies over the default behavior of a data service. Following the tenants of SOA, this helps data services stay generic and reusable across multiple consumers and decouples an architecture's security concerns from its data access.

William Dettelback currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions.