Skip navigation.

eDocs Home > BEA AquaLogic Data Services Platform BEA 2.0.1 Documentation > Administration Guide > Securing Data Services Platform Resources

Administration Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

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

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

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:

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:

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 Data Services Platform artifacts is as follows:

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

Figure 6-2 Securable Resources

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:

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://download.oracle.com/docs/cd/E13222_01/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 under Console Access Control.
  2. Choose a condition from the Policy Condition list box.

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

    Figure 6-3 Policy Condition Editor

    Policy Condition Editor


     
  3. Click Add.

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


       


       
  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.

    6. 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://download.oracle.com/docs/cd/E13222_01/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://download.oracle.com/docs/cd/E13222_01/wls/docs81/secwlres/secroles.html

 

Securing DSP Resources

You can secure 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

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 application access policy:

  1. Select the application node in the Navigation pane.

    2. Figure 6-5 Securing an Application

    Securing an Application


     
  2. Click the Check Access Control box in the Access Control area of the General tab.

    3. When this option is selected, access to all resources is blocked by default and security policies are applied. You can either keep this restrictive policy as the default and selectively configure security policies on individual resources, or choose to permit access by default.

  3. If you want to permit user access to resources by default, enable the Allow default anonymous access option.

    4. This permits access to all resources, even to unauthenticated users, unless a more specific policy blocks it.

  4. Click Apply.

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 submit function. A submit function allows users to save data changes to back-end data sources. Function-level security policies enable you to control who can use data service functions and when. This enables you to set stricter controls on the ability to change data, for example, compared to the ability to read data.

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 an another data service, the policy is not evaluated against the caller.

Note: 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.

To create a function 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.

    3. The functions in the data service appear, as illustrated in Figure 6-6.

    Figure 6-6 Security Policy Function List

    Security Policy Function List


     
  3. Click the Action icon (Security Policy Function List ).
  4. Use the WebLogic Policy Editor to create a policy for the function.

    5. For more information, see Using the WebLogic Policy Editor.

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

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.

Warning: Any element for which you want to create a security policy must be defined as optional or repeating in the schema definition of the data service type. Mandatory elements in the schema definition are not securable to ensure conformance with the XSD.

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.

    3. The functions in the data service appear.

  3. Click the Secured Elements tab.

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

    Figure 6-7 Secured Elements Tab

    Secured Elements Tab


     
  4. Select the check box for the data elements you want to secure.

    5. Selecting a parent node includes all children of the parent.

  5. Click Apply.
  6. Click the Security Policy tab.

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

    8. Click the Action icon (Secured Elements Tab ) to create a security policy. Click the Security XQuery function icon (Secured Elements Tab ) 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.

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.

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

    Figure 6-8 Security XQuery Functions

    Security XQuery Functions


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

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

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

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

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

Data Services Platform provides the following additional convenience functions for security purposes:

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:

  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.

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

    Figure 6-9 Applying Security XQuery Functions

    Applying Security XQuery Functions


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

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


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

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

    9. 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:

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.

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

To export the file:

  1. Select the application node in the Navigation pane.

    2. The General application settings page appears.

  2. Click the Export access control resources link.

    3. The File Save dialog appears.

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

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

Resource Identifier Format


 

The resource can be any of the following:

These are generated when you select an element in the Secured Element tab of the DSP Console, as shown in Figure 6-12.

Figure 6-12 Element Resources

Element Resources


 

 

Skip navigation bar  Back to Top Previous Next