Administration Guide

Securing AquaLogic Data Services Platform Resources

This chapter describes how to secure AquaLogic Data Services Platform resources, in particular, how to control access to those resources.

The chapter contains the following sections:

Introducing AquaLogic Data Services Platform Security

AquaLogic Data Services Platform uses the security features of the underlying WebLogic platform to ensure the security of the information it provides. Specifically, AquaLogic Data Services Platform uses role-base security policies to control access to data resources.

For a secured resource, a requesting client must meet the condition of the security policy applicable to that resource, whether accessing the resource through the typed mediator API, an ad hoc query, or any data access interface. A typical condition is based on the role of the user identified by the credentials passed by the client. But other types of conditions are possible as well, including policies based on time of day or user identity.

AquaLogic Data Services Platform exposes its deployed artifacts as resources that can be secured through WebLogic role-based security policy control. With AquaLogic Data Services Platform, you can apply security policies at various levels, from the application to individual data elements. This range gives you significant flexibility. For example, you can control access to an entire AquaLogic Data Services Platform deployment or just to a credit card number element in an order.

When a request comes to AquaLogic Data Services Platform for a secured resource, AquaLogic Data Services Platform passes an identifier for the resource to WebLogic. WebLogic, in turn, passes the resource identifier, user name, and other context information to the authorization provider. The provider evaluates the policy that applies to the resource given the information passed by WebLogic. 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—it does not appear.

Figure 6-1 Data Redaction

Note:

By default, WebLogic security uses the ATZ authorization provider module. ATZ keeps policies in an LDAP system. Other authenticators can use any external resource necessary to implement the policy evaluation.

Setting up AquaLogic Data Services Platform security in the AquaLogic Data Services Console involves one or more of these tasks:

Turning on access control checking for the application. Security policies are not applied unless this option is selected.
Specifying the global, application-level default policy for anonymous users.
Configuring security policies for data service functions.
Identifying data elements that you want to secure and then configuring either security policies or custom XQuery security functions for the elements.

Note:

Keep in mind that AquaLogic Data Services Platform directly supports the application of role-based security policies to its resources. The WebLogic Platform supports extensive security features that can be applied to your implementation as well, including encryption-based, transport-level security.

Note:

For information on WebLogic Server security, see Managing WebLogic Securityin the WebLogic Server documentation.

You can also apply access controls to the AquaLogic Data Services Console interface itself. You can control user access to specific functionality in the console, for example, limiting developer access to the Metadata Browser portion of the console.

What is a Securable Resource?

A securable resource is a AquaLogic Data Services Platform artifact, such as a data element or function, to which you can apply a security policy. The resources you can protect with role-based security include:

Functions. The policy applies to individual data service functions in an application.
Data elements. A policy can apply to individual items of information within a return type, such as the salary property of a customer.

Note:

When using a custom Authorization provider (other than the default WebLogic Authorization provider) you can also configure policies for data services. A data service policy applies to any of the data service's functions and data elements. See Exporting Access Control Resources on page 6-21 for more information about using custom Authorization providers.

Once you have secured individual resources, you can enable or disable security for the application. Security policies are inherited. This means that security enabled at the application level applies to all functions and elements within the application. If several policies apply to a particular resource, the more specific policy prevails. Therefore, for example, a policy on an element supercedes a policy for the data service.

The hierarchy of AquaLogic Data Services Platform artifacts is as follows:

Application
Data service
Function
Data element

Figure 6-2 illustrates the securable resources in a AquaLogic Data Services Platform application.

Figure 6-2 Securable Resources

Enabling anonymous access is a special type of application-level setting. It enables you to either disable access to the application by default (unless a more specific policy permits it) or enable access (unless a more specific policy blocks it). If enabled, all users can access resources by default, even unauthenticated users. The anonymous access option works only with the WebLogic Authorization provider.

Note:

Note that the AquaLogic Data Services Console itself constitutes an administrative resource you can secure with security policies.

Understanding Security Policies

A security policy is a condition that must be met for a secured resource to be accessed. If the outcome of condition evaluation is false—given the policy, requested resource, and user context—access to the resource is blocked and associated data is not returned.

Policies can be based on the following criteria:

User Name of the Caller. Creates a condition for a security policy based on a user name. For example, you might create a condition indicating that only the user John Smith III can access the Customer data service.
Caller is a Member of the Group. Creates a condition for a security policy based on a group. For example, you might create a condition indicating that only members of the finance group can access the Accounts data service.
Caller is Granted the Role. Creates a condition based on a security role. A security role is a special type of user group for managing the common security needs of a group of users.
Hours of Access are Between. Creates a condition for a security policy based on a specified time period.
Server is in Development Mode. Creates a condition for a security policy based on whether the server is running in development mode.

The security policies you configure in the AquaLogic Data Services Console are intended to work with the default WebLogic Authorization provider. If you are using another provider, you will need to create policies using the facilities of the other provider. For more information, see "WebLogic Authorization Provider" in the Administration Console Online Help at:

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/security_defaultauthorizer_general.html

Using the WebLogic Policy Editor

The AquaLogic Data Services Console incorporates the WebLogic Policy Editor interface for creating AquaLogic Data Services Platform security policies. You can use the policy editor for both AquaLogic Data Services Platform application resources — such as data elements and functions — and administrative resources.

To create a policy using the WebLogic Policy Editor:

In the Data Services Platform Console click on Administration Policies under Console Access Control.
Choose a condition from the Administration Policies list box.

You can select any of the policy criteria listed, as shown in Figure 6-3.

Figure 6-3 Policy Condition Editor

Policy Condition Editor

Click Add.

The window that appears depends on the condition you selected, as follows:

If you selected the Server is in Development Mode condition, no window appears. Instead the completed expression appears in the Policy Statement list box.
If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, and click OK. The window closes and an expression appears in the Policy Statement list box.
If you selected one of the other conditions, use the Users, Groups, or Roles window to enter the name of a user, group, or security role, and click Add. An expression appears in the list box, as shown in Figure 6-4. Repeat this step to add more than one user, group, or security role, and click OK to add the expression to the policy statement. The window closes and an expression appears in the Policy Statement list box.

Figure 6-4 Policy Composition Window

Policy Composition Window

If needed, repeat steps 1 and 2 to add expressions based on different policy conditions.
After adding a policy, use the buttons located to the right of the Policy Statement list box to modify the expressions.

The buttons enable you to do the following:

Move Up/Move Down. Changes the order of the highlighted expression, and therefore the order in which the expressions are evaluated.
Change. Toggles the compound operator that combines the selected expression and the previous expression between "and" and "or".
Edit. Reopens the edit window for the highlighted expression.
Remove. Deletes the highlighted expression.

Click Apply to save the security policies.

For more information on WebLogic security policies, see the WebLogic documentation at:


http://download.oracle.com/docs/cd/E13222_01/wls/docs81/secwlres/sec_poly.html

Securing Data Services Platform Resources

You can secure AquaLogic Data Services Platform resources by application, data service function, and element. An element-level security policy applies to all functions in the data service that use the data element.

To use element or function-level security, you must first specify access control checking for the application. Security policies are not applied to users unless access control checking is enabled.

This section describes the following topics:

Securing Applications

Three optional checkboxes set security for your application (Figure 6-5). These are:

Check Access Control
Allow Default Anonymous Access
Enable JDBC Metadata Access Control

These option are not mutually exclusive. In a deployed application, generally speaking, you would always want access control enabled.

Each of these options is described in this section.

Figure 6-5 Securing a AquaLogic Data Services Platform-Enabled Application

Enabling Security Access Control

Enabling access control checking activates the checking of policies throughout the application by the WebLogic Server authorization provider. Once access control checking is activated, access to any resource in the application is determined by the policy on that resource.

By default, access control is not enabled.

WARNING:

If the access control option is not selected, none of the data in your application is secure.

Allowing Default Anonymous Access

For the default authorization provider, if access control is enabled and no specific overriding resource policy is defined, access will be denied.

You can "invert" access control policies by selecting the allow default anonymous access option. Or, put another way, if anonymous access is enabled, access to application resources is enabled unless a more specific policy blocks access.

Note:

This option only applies to the default authorization provider in the WebLogic Server security framework. It works by defining a policy rule applied to a common parent resource of application resources.

By default, anonymous access is enabled.

Note:

If you do not select this option, then you need to either selectively configure security policies on individual resources, or disable access control checks for all resources by clearing the Check Access Control option. The second option is not recommended.

Enabling JDBC Metadata Access Control

You can control metadata accessed through SQL by selecting the Enable JDBC Metadata Access Control option. This option allows AquaLogic Data Services Platform 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 which 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.

Steps to Setting Security Policies for an Application

To set the access policy for a AquaLogic Data Services Platform-enabled Workshop application follow these steps:

Select the application node in the Navigation pane. (The security policy dialog box should appear similar to that shown in Figure 6-6.)
Establish whether access control is active or not. See Enabling Security Access Control.

WARNING:

If access control is not selected, then security is not enabled for your application.

Determine whether default anonymous access is allowed. See Allowing Default Anonymous Access.
Determine whether access policies are to apply to AquaLogic Data Services Platform metadata accessed through SQL. See Enabling JDBC Metadata Access Control for details.
Click Apply at the bottom of the General Application settings.
Finally, you can set function or element level security policies, as well as control metadata access, on AquaLogic Data Services Platform resources. See Securing Data Service Functions and Securing Data Elements.

Securing Data Service Functions

A data service typically has several functions, including one or more read functions, navigation functions, and a single submit function. A submit function allows you to update back-end data sources. Function-level security policies enable you to control:

User access to data service functions. Enables you to set stricter controls on the ability to change data, for example, compared to the ability to read data.
Access times to data service functions. Enables you to control the times when a particular function can or cannot be accessed.

WARNING:

Be sure to 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.

WARNING:

For the purposes of security, data service functions are identified by name and number of parameters. This means that if you modify the number of parameters, you will need to reconfigure the security settings for the function.

Creating Function Security Policies

To create a function security policy:

Expand the folder containing the data services for which you which to establish function security policies. This folder is located below server application folder in the Navigation pane (see Figure 6-6).
Select the data service you want to configure.
Select the Admin tab.
Select the Security tab. The functions in your data service appear as resource names.

Figure 6-6 Security Policy Function List

Security Policy Function List

Click the Action icon ().
Use the WebLogic Policy Editor to create a policy for the function.

For more information, see Using the WebLogic Policy Editor.

Note:

You must enable access control for the application in order to have function-level security policies applied to users. For more information, see Securing Applications.

The other options shown in Figure 6-6 are described under Creating Security Defaults for Data Elements.

Securing Data Elements

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

An element-level security policy applies across all functions of the data service but not to any other data services. In other words, a security policy set on a particular data service is not inherited. If the same data composes another data service, either from the source or as an inclusion of the data service on which the policy is configured, the policy does not apply to users of those data services.

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

To configure a data element security policy:

Expand the data services folder under the application node in the Navigation pane.
Select the data service you want to configure, and click the Security tab.

The functions in the data service appear.

Click the Secured Elements tab.

A tree representing the data type appears, as illustrated in Figure 6-7.

Figure 6-7 Secured Elements Tab

Secured Elements Tab

Select the check box next to the data elements you want to secure. Selecting a parent node includes all children of the parent.
Click Apply.
Click the Security Policy tab (Figure 6-6). The element now appears in the resources list as an element type.
Create a security policy or a custom security condition for the element.

Click the Action icon ( Secured Elements Tab ) to create a security policy. Click the Security XQuery function icon () to create a custom security condition.

For more information, see Using the WebLogic Policy Editor or Using Data-Driven Security Policies.

Note:

You must enable access control for the application to have the data element-level security policies applied to users. For more information, see Securing Applications.

Creating Security Defaults for Data Elements

The security defaults feature allows you to specify fixed values (or mandatory elements) for any data service fields with a return types. These values are used in cases where access control restricts access to the data service.

There are three ways to represent a secured field on which access is restricted:

Omit the field from returned data. In this case the element or attribute is removed from the result. This can only be done when the element or attribute is optional.
Provide a default value for the field. The element or attribute is assigned a constant value. Only primitive values are permitted; complex types cannot have default values.
Supply an empty value for the field. This is the case where the default value supplied for the field is an empty string. This can only be used for types that allow an empty string as a valid value.

These settings are achieved through the data service security policy list (Figure 6-6). The options available are shown in Table 6-1.

Table 6-1 Data Service Security Policy List Options

Option

Meaning

Always Use Tags

If selected, the secured field will always be placed in the result and contain the default value if access is restricted.

If the option is not selected, the secured field will be omitted if access is restricted. In this case the default value is never used.

The check box is, by default, be selected for mandatory element/attributes. It is, by default, set to an unselected state for complete type elements and for optional elements and attributes.

Default Value

This field contains any default value you want to assign for attributes or elements. The default value is returned only if the Always Use Tag is also selected.

By default, the contents of the field is an empty string.

Note:

No type or other validation is performed on the entered default value. Thus you should ensure the validity of enter values to avoid unexpected problems.

Using Data-Driven Security Policies

A security XQuery function 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.

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

You can apply security XQuery functions to any element resource. Applying data-driven security policies involves the following steps:

Identify the element as a secured element. (For more information, see Securing Data Elements.)
Create a security XQuery function to define the data-level security. (For more information, see Creating a Security XQuery Function.)
Apply a security XQuery function to a data element. (For more information, see Applying a Security XQuery Function.)

Creating a Security XQuery Function

You can create one or more security XQuery functions to apply against data elements in an application. You define the functions in the Security XQuery Functions tab.

To create a security XQuery function:

Select the application node in the Navigation pane.
Click the Security XQuery Functions tab.

Existing XQuery functions are displayed, as illustrated in Figure 6-8.

Figure 6-8 Security XQuery Functions

Security XQuery Functions

Add the XQuery function body in the text area of the tab.

Add as many functions as required. 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 be qualified by a namespace.

After adding the function text, click Compile.

An output window provides feedback on the compilation.

Note:

For details on creating XQuery functions, see AquaLogic Data Services Platform XQuery Developer's Guide.

Click Apply when you have finished adding functions.
Redeploy the application from the WebLogic Administration Console for the changes to take effect.

To redeploy the application:

Open the WebLogic Administration Console.
Select Deployments Applications application_name in the domain tree to open the application configuration page.
Click the Redeploy tab, and click Redeploy Application.

The return value of the function determines whether access is granted as follows:

True. Access is permitted to the element protected by the function.
False. Access is blocked.

The following shows an example of a simple 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()

else if ($order/TotalOrderAmount lt (fn-bea:get-property("total_order_amount", "1000000") cast as xs:decimal))

then

      fn:true()

else

      fn:false()

};

Note:

A security XQuery function must be applied to a data element for it to take effect. For more information, see Applying a Security XQuery Function on page 6-18.

Notice that the function uses the BEA 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 a element name and a resource identifier.

AquaLogic Data Services Platform 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.

Applying a Security XQuery Function

You can use security XQuery functions to control access to data elements. Once you have defined the security XQuery function, as described in Creating a Security XQuery Function on page 6-16, you must apply the function to a data element for it to take effect.

To apply a security XQuery function:

Select a data service in the Navigation pane, and click the Secured Elements tab.
Choose the data element to which you want to apply a custom function.
Click the Security Policy tab.

The Security Policy page appears, as illustrated in Figure 6-9.

Figure 6-9 Applying Security XQuery Functions

Applying Security XQuery Functions

Click the security XQuery function icon () corresponding to the data element you want to secure.

Figure 6-10 illustrates the dialog that appears enabling you to add the qualified name of the security function.

Figure 6-10 Applying a Function to an Element

Applying a Function to an Element

Click Add, and enter the Namespace URI and local name of the function to be applied to the data element.
Click Submit.

Optionally, you can remove a function or add additional functions by clicking the Remove and Add buttons respectively.

Click Close.
Redeploy the application from the WebLogic Administration Console for the changes to take effect.

To redeploy the application:

Open the WebLogic Administration Console.
Select Deployments Applications application_name in the domain tree to open the application configuration page.
Click the Redeploy tab, and then Redeploy Application.

Securing Access to the Data Services Platform Console

Similar to the WebLogic Administration Console, the AquaLogic Data Services Console is itself an administrative resource for which you can control access using security policies. If a policy blocks a user from accessing a page, the page is omitted from the console.

Security policies control access by functional category of the page. The pages are divided into the following functional categories:

Administration pages. Allows users to configure the deployment, for example, by setting cache and security policies.
Metadata pages. Provide information on data services. They give users a read-only view of the type of information provided by data services, their names, data types, functions, and so on. You can specify policies that control who can access console pages based on this classification.

To create a policy:

Expand the Console Access Control node in the Navigation pane, and choose one of the following:

Administration. This enables you to specify policies for accessing AquaLogic Data Services Platform configuration pages in the console.
Metadata Browser. This enables you to specify policies for accessing the Metadata information tabs. The Metadata Browser is intended for AquaLogic Data Services Platform administrators and developers who want to use AquaLogic Data Services Platform services in their applications.

Add policy conditions for the resource, as appropriate.

For more information on creating security policies, see Understanding Security Policies.

Click Apply when finished.

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 AquaLogic Data Services Platform artifacts, such as applications, data services, and functions. 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 AquaLogic Data Services Console to configure your policies. In particular, resource identifiers already exist for AquaLogic Data Services Platform applications, their data services, and data service functions. 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 will need to 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 will need to identify the element resources that you want to protect.

Note:

The WebLogic security documentation provides details on how to connect another security authenticator to WebLogic. For more information, see "WebLogic Authorization Provider" in the Administration Console Online Help at:


http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/security_defaultauthorizer_general.html

You can view the list of resource identifiers by exporting the access control resources from the AquaLogic Data Services Console.

To export the file:

Select the application node in the Navigation pane.

The General application settings page appears.

Click the Export access control resources link.

The File Save dialog appears.

Choose the location where you want to save the file, and click OK.

An example of a portion of the file follows:

<ld type="app"><app>RTLApp</app></ld> <ld type="service><app>RTLApp</app><ds>ld:DataServices/ElectronicsWS/ getProductList.ds</ds></ld> <ld type="function"><app>RTLApp</app><ds>ld:DataServices/ElectronicsWS/ getProductList.ds</ds><res>{ld:DataServices/ElectronicsWS/ getProductList}getProductList:1</res></ld> <ld type="submit"><app>RTLApp</app><ds>ld:DataServices/ElectronicsWS/ getProductList.ds</ds><res>ld:submit</res></ld> <ld type="service><app>RTLApp</app><ds>ld:DataServices/RTLServices/ OrderSummaryView.ds</ds></ld> <ld type="custom"><app>RTLApp</app><ds>ld:DataServices/RTLServices/ OrderSummaryView.ds</ds><res>ORDER_SUMMARY/ORDER_SUMMARY/ LINE_ITEM</res></ld>

The format of a resource identifier is shown in Figure 6-11.

Figure 6-11 Resource Identifier Format

The resource can be any of the following:

Function. A data service function, for example, {ld:DataServices/ElectronicsWS/ getProductList}getProductList:1
Submit operation. For example, ld:submit.
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 function, for example.

These are generated when you select an element in the Secured Element tab of the AquaLogic Data Services Console.