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

• 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://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:

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

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

Figure 6-3 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




 

 
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

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

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:

Select the application node in the Navigation pane.

Figure 6-5 Securing an Application




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

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.

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

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

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:

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, as illustrated in Figure 6-6.

Figure 6-6 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 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:

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




 

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

Selecting a parent node includes all children of the parent.

Click Apply.
Click the Security Policy tab.

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

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




 

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 DSP 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="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:

• 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




 

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




 

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

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

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 DSP Console, as shown in Figure 6-12.

Figure 6-12 Element Resources