Skip navigation.
Downloads | Product Documentation | Support

Administration Guide

# Securing 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 Data Services Platform Security
- What is a Securable Resource?
- Understanding Security Policies
- Securing Data Services Platform Resources
- Securing Access to the Data Services Platform Console
- Exporting Access Control Resources

# Introducing Data Services Platform Security

DSP (Data Services Platform) uses the security features of the underlying WebLogic platform to ensure the security of the information it provides. Specifically, 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.

Data Services Platform exposes its deployed artifacts as resources that can be secured through WebLogic role-based security policy control. With 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 Data Services Platform deployment or just to a credit card number element in an order.

When a request comes to Data Services Platform for a secured resource, 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 Data Services Platform security in the DSP 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 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.

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

You can also apply access controls to the DSP 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 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-22 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 Data Services Platform artifacts is as follows:

- Application
- Data service
- Function
- Data element

Figure 6-2 illustrates the securable resources in a 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 DSP 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 DSP 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://e-docs.bea.com/wls/docs81/ConsoleHelp/security_defaultauthorizer_general.html

### Using the WebLogic Policy Editor

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

To create a policy using the WebLogic Policy Editor:

1. In the Data Services Platform Console click on Administration Policies under Console Access Control.
2. 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

3. 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

4. If needed, repeat steps 1 and 2 to add expressions based on different policy conditions.
5. 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.

6. Click Apply to save the security policies.

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

>     http://e-docs.bea.com/wls/docs81/secwlres/sec_poly.html

## User Role Considerations

In a WebLogic domain, a user group is a logical collection of users. A role is similar to a group, except that while membership in a group is statically defined, membership in a security role is dynamically allocated based on factors such as user name, group membership, or time of day.

In WebLogic there are two types of roles, global and scoped. Scoped roles prevent naming conflicts with roles configured for securing other WebLogic resources. DSP, however, only supports global roles. Therefore, when creating roles for use with Data Services Platform security, you may want to name the roles with a distinguishing prefix, such as "ld_" (for example, ld_admin).

For more information on WebLogic security roles, see the following WebLogic documentation:

>     http://e-docs.bea.com/wls/docs81/secwlres/secroles.html

# Securing Data Services Platform Resources

You can secure DSP 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 on page 6-10
- Securing Data Service Functions on page 6-12
- Securing Data Elements on page 6-13
- Using Data-Driven Security Policies on page 6-16

## Securing Applications

Enabling access control checking activates the security policies in the application. Once access control checking is turned on, access to any resource in the application is blocked unless a more specific policy (one at the data service, function, or element level) permits it for a user.

You can invert this rule by enabling default anonymous access. If this option is selected, access to application resources is enabled by default, unless a more specific policy blocks access.

To set the access policy for a DSP-enabled Workshop application:

1. Select the application node in the Navigation pane.

Figure 6-5 Securing a DSP-Enabled Application

2. Establish whether access control is active or not. When the Check Process Control option is selected, security is managed by the WebLogic Server default authorization provider. This means that security policies are applied for functions, elements, etc.

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

1. Establish whether to allow default anonymous access or not. By default, this option is selected. This means that various elements in your application will be available to all users, even unauthenticated users. If you uncheck this option you can either selectively configure security policies on individual resources, or choose to permit access to all resources by default by also deselecting the Check Access Control option.
2. Click Apply at the bottom of the General Application settings.

If access control is active you can now set function or element level security policies on Data Services Platform resources.

## 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.
- Fixed values (or mandatory elements) for any return type data service fields. Enables you to specify, for example, that default value is supplied to a particular field.

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:

1. 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).
2. Select the data service you want to configure.
3. Select the Admin tab.
4. Select the Security tab. The functions in your data service appear as resource names.

Figure 6-6 Security Policy Function List

5. Click the Action icon ( ).
6. 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. However, note that it applies only in the context of that data service. 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:

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

The functions in the data service appear.

3. Click the Secured Elements tab.

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

Figure 6-7 Secured Elements Tab

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

Click the Action icon ( ) 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 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

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:

1. Identify the element as a secured element. (For more information, see Securing Data Elements.)
2. Create a security XQuery function to define the data-level security. (For more information, see Creating a Security XQuery Function.)
3. 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:

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

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

Figure 6-8 Security XQuery Functions

3. 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.

4. After adding the function text, click Compile.

An output window provides feedback on the compilation.

Note: For details on creating XQuery functions, see DSP XQuery Developer's Guide.

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

To redeploy the application:

1. Open the WebLogic Administration Console.
2. Select Deployments —>Applications —>application_name in the domain tree to open the application configuration page.
3. 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="test:demo";
>     declare namespace
>       itemns="http://temp.openuri.org/DataServices/schemas/CustomerProf.xsd";

>     declare function demo:secureCustomer($ssn as xs:string) as xs:boolean {
>     if (fn-bea:is-access-allowed("ssn", "ld:DataServices/CustomerProfile.ds"))
>             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-19.

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.

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-17, you must apply the function to a data element for it to take effect.

To apply a security XQuery function:

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

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

Figure 6-9 Applying Security XQuery Functions

4. 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

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

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

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

To redeploy the application:

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

# Securing Access to the Data Services Platform Console

Similar to the WebLogic Administration Console, the DSP 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:

1. 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 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 Data Services Platform administrators and developers who want to use Data Services Platform services in their applications.

2. Add policy conditions for the resource, as appropriate.

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

3. 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 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 DSP Console to configure your policies. In particular, resource identifiers already exist for 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://e-docs.bea.com/wls/docs81/ConsoleHelp/security_defaultauthorizer_general.html

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

To export the file:

1. Select the application node in the Navigation pane.

The General application settings page appears.

2. Click the Export access control resources link.

The File Save dialog appears.

3. 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 DSP Console.