Skip navigation.

eDocs Home > BEA Liquid Data for WebLogic 8.1 Documentation > Administration Guide > Security in Liquid Data

Administration Guide

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

Security in Liquid Data

This chapter describes the security infrastructure in BEA Liquid Data for WebLogic, and includes information on how to activate the security system and how to set security attributes on Liquid Data objects. It contains the following sections:

 

Overview of Liquid Data Security

The security infrastructure in Liquid Data extends the security policies in WebLogic Server to include Liquid Data objects such as data sources and stored queries in addition to setting up security roles, groups, and users. These security policies allow Liquid Data administrators to set up rules which dynamically determine whether a given user:

Although Liquid Data is always enabled, by default Liquid Data objects do not have any security policies configured. Therefore an object is generally accessible unless a more restrictive policy for the object is configured.

You use the Liquid Data node of the WebLogic Administration Console to configure security in Liquid Data, which includes the following tasks:

Note: Compatibility security, which uses the WebLogic 6.1 security infrastructure, is not supported in Liquid Data 8.1.

Note: The Liquid Data security model simply extends the WebLogic Server security model, therefore the information in the WebLogic Server security documentation applies to Liquid Data.

Defining Liquid Data Roles and Groups

Based on the role granted to a particular user or group, Liquid Data node of the WebLogic Administration Console access to an object can be restricted or a combination of read/write/execute permissions applied.

Domains created or extended for Liquid Data by the WebLogic Configuration Wizard automatically set up Liquid Data security roles and groups, including the required LDAdmin role.

Under some circumstances, however, it may be necessary or desirable to manually create Liquid Data security management. You can do this through the Security node of the WebLogic Administration Console.

The following sections are included:

Basic Administration Console Access Requirements

To use the Liquid Data node of the WebLogic Administration Console, a user or a group to which the user belongs must be able to access the Administration Console.

Only a user or group assigned the LDAdmin role has unrestricted access to the Liquid Data node of the WebLogic Administration Console. A more restrictive role called LDConsole is also available in domains created using the Liquid Data WebLogic Configuration Wizard.

For more details on Liquid Data roles and groups see Using Liquid Data Pre-Defined Security Roles and Groups on page 19-3.

If you are not using one of the Liquid Data domains available from the WebLogic Configuration Wizard, you can create your own roles and groups. Since the LDAdmin role is required to administer Liquid Data, creating an LDAdmin role and assigning a user or group to that role is a requirement. See Manually Creating Liquid Data Groups and Roles on page 19-5.

Using Liquid Data Pre-Defined Security Roles and Groups

When you create or extend a domain for Liquid Data using the WebLogic Configuration Wizard, the following roles and groups are automatically pre-defined:

This arrangement, described in Table 19-1, provides for granting users and groups appropriate levels of access to the Liquid Data node of the WebLogic Administration Console.

Note: In some situations — such as when data source security handled externally to the WebLogic Platform — you will need to define your roles and groups manually. See Manually Creating Liquid Data Groups and Roles on page 19-5.

`

Table 19-1 Pre-Defined Roles and Groups in Liquid Data Domains. 

Name

Description

LDAdmin role

The LDAdmin role is required to administer Liquid Data. The LDAdmin role can:

  • Create, modify, and delete data source descriptions.

  • Create, modify, and delete directories and files in the Liquid Data repository.

As a member of the LDAdministrator's group-, the LDAdmin has complete access (Read, Write, and Execute) to all Liquid Data resources, as well as unrestricted access to the Liquid Data node of the WebLogic Administration Console.

As pre-defined in the WebLogic Configuration Wizard, the LDAdmin role is assigned to the LDAdministrators group. You can assign this role to individual users or groups to have the same effect as adding them to the LDAdministrators group.

Note: For the most efficient management, BEA recommends granting security roles to groups rather than individual users.

LDConsole role

The optional LDConsole role is designed for users needing access to the Liquid Data node of the WebLogic Administration Console, but who can only access resources to which they have permissions.

The LDConsole role can access the Liquid Data node of the WebLogic Administration Console, but can only read and modify resources to which they have appropriate permissions (granted or revoked via security policy, for example).

As pre-defined in the WebLogic Configuration Wizard, the LDConsole role is assigned to the LDConsoleUsers group. You can assign this role to individual users or groups to have the same effect as adding them to the LDConsoleUsers group.

Note: For the most efficient management, BEA recommends granting security roles to groups rather than individual users.

LDAdministrators group

The LDAdministrators group has the LDAdmin role. Therefore it has complete access (Read, Write, and Execute) to all Liquid Data resources. Any user who is a member of the WebLogic Server Administrators group is automatically a member of the LDAdministrators group.

LDConsoleUsers group

The LDConsoleUsers group has the LDConsole role. Therefore it has access to the Liquid Data console, but can only read, write, or execute resources to which they have permissions.

For example, if a user Joe is a member of the LDConsoleUsers group, but is explicitly denied access to the Liquid Data Relational Data Source named mySource (through a security policy, for example), then Joe can log into the console but will not be able to see or modify the mySource data source.


 

You add users or groups to the LDAdmin or LDConsole roles through WebLogic Administration Console Security node, as described in Setting Up Liquid Data Administrator Users. For details on managing WebLogic security, see Managing WebLogic Security in the WebLogic Server documentation.

Manually Creating Liquid Data Groups and Roles

As noted in Basic Administration Console Access Requirements on page 19-3, only the unrestricted role named LDAdmin can fully manage Liquid Data. (See Using Liquid Data Pre-Defined Security Roles and Groups on page 19-3 for suggested Liquid Data security administration structure.) For details on setting up security groups and roles see Initializing Liquid Data Security on page 19-7.

Note: The Liquid Data security model extends the WebLogic Server security model, the information in the WebLogic Server security documentation applies to Liquid Data.

Creating Liquid Data Security Resource Groups

Liquid Data allows you to create security resource groups, which are string prefixes for object names that you can configure with a security policy. The security policy is then inherited by any object in which the name is prefixed by the string.

For example, if you create a security resource with the name accounting and set up a security policy that allows execute access to the Accountants group, then any objects prefixed with the string accounting. (the period character is required) automatically is executable only by members of the Accountants group.

For the procedure for defining security resources groups, see Defining Liquid Data Security Resource Groups.

Configuring Security Policies on Liquid Data Objects

You can configure security policies for the Liquid Data resources such as stored queries, data sources, repository directories, and file security. For more information, see Assigning Security Policies to Liquid Data Objects.

Query Security

Query security depends on whether the query is a stored query or an ad-hoc query. For custom functions associated with a query, access is determined by the security policy associated custom function as well as the security policy associated with any data sources used by the custom function (if it uses any data sources).

Stored Queries

For stored queries, access is determined by the security policy associated with the file name of the stored query and/or with the directory and/or subdirectories of the stored query. The security policy is assigned to the stored query in the Administration Console, as described in Assigning Security Policies to Liquid Data Objects. At run time, Liquid Data checks that the user who submitted the query request has execute permission to the stored query before submitting the query to the Liquid Data server for processing.

Ad Hoc Queries

For ad-hoc queries, access is determined by the security policy associated with the data source(s) that the query attempts to access, as described in Data Source Security. The security policy is assigned to the data source in the Administration Console. At run time, the Query Engine checks that the user who submitted the request has execute permission to all data sources associated before processing the query.

Data Source Security

For all data sources, access is determined by the security policy associated with the data source description. The security policy is assigned to the data source description using the Administration Console. For more information, see Configuring Secure Access to Data Source Descriptions.

For the following types of data sources, additional steps are required to configure data access security.

Repository Directory and File Security

You can control access to directories and files in the repository by assigning security policies to individual directories or files using the Administration Console. You can assign security policies to stored queries, data views, XML files, web service definitions, SQL Calls, and custom functions. For more information, see Configuring Secure Access to Items in the Server Repository.

 

Initializing Liquid Data Security

Before you can configure security policies on Liquid Data objects, there are several initialization tasks you need to perform. This section describes those tasks and contains the following sections:

Making Sure Your Domain Includes Liquid Data

You must have Liquid Data enabled in the domain in order to use any part of Liquid Data, including the Liquid Data security. You can use the WebLogic Configuration Wizard to create a Liquid Data domain or to add Liquid Data to an existing domain. For details, see the Liquid Data Deployment Guide.

To verify that Liquid Data is enabled in the domain, check that the following exist in your domain:

If you use the Domain Configuration Wizard to create your Liquid Data domain or to add Liquid Data to an existing domain, these objects are all automatically created.

Setting Up Liquid Data Administrator Users

If you want a user or group to have administrative access to all objects in the Liquid Data Administration Console, you must assign the user or group to have the LDAdmin role.

Figure 19-2 Grant LDAdministrators Group Membership to a User

Grant LDAdministrators Group Membership to a User


 

Users who are members of the WebLogic Server Administrators group automatically are members of the LDAdministrators group, so there is no need to grant those users membership in the LDAdministrators group.

Similarly, if you used the WebLogic Configuration Wizard to create or extend your domain, security setting options allow for extending LDAdmin membership to other users or groups.

If you are not using the WebLogic Configuration Wizard and you want other users to have access to all Liquid Data resources, then you must:

  1. Assume the LDAdmin role and
  2. Explicitly assign the user or group to have the LDAdmin role.

Setting Up Liquid Data Console Users

If you want a user or group to be able to log into the Liquid Data console but only have access to objects to which he has permission defined (through a security policy, for example), you can assign the user or group the LDConsole role. If you have created a domain using the WebLogic Configuration Wizard, you can add users or groups to the LDConsole role by adding them to the LDConsoleUsers group.

Figure 19-3 Grant LDConsoleUsers Group Membership to a User

Grant LDConsoleUsers Group Membership to a User


 

Users who are members of the Administrators group automatically have all of the privileges associated with the LDConsoleUsers group, so there is no need to grant those users membership in the LDConsoleUsers group.

Similarly, if you used the WebLogic Configuration Wizard to create or extend your domain, security setting options allow for extending LDAdministrator membership to other users or groups.

If you are not using the WebLogic Configuration Wizard and you want other users to have access to all Liquid Data resources, then you must:

  1. Assume the Administrators role and
  2. Explicitly assign the user or group to have the LDConsoleUsers group.

 

Defining Liquid Data Security Resource Groups

Security resource groups are prefixes to object names that you configure with a security policy. Objects with names beginning with the prefix followed by a dot (.) automatically inherit the security policy of the resource group. If you change the security policy of the resource group, the security policy of all objects with the prefix also changes.

Note: Security resource groups only apply to data sources and custom functions; they do not apply to repository folders and they do not apply to stored queries. For information on how security works on repository objects and folders, see Configuring Secure Access to Items in the Server Repository.

Nested Levels of Security Resource Groups

You can create multiple levels of security resource groups that inherit security policies from the parent nested resource group. Each of these nested levels must include the name of the inherited resource group as a prefix. If you create such nested resource groups, the permissions of the higher-level parent groups should be a higher level (less restrictive) of permissions than those of the lower-level (more restrictive) groups, otherwise the lower-level groups will try to get permissions that they are implicitly denied by the higher-level groups, making the lower-level groups have no net effect on the security policy.

Example

Consider a security resource group named marketing that has READ and EXECUTE access to the marketing data sources. You can then name the marketing data sources with the marketing prefix as follows:

marketing.WebService
marketing.OracleDB
marketing.CRM

These data sources automatically inherit the security policy of the marketing security resource group.

Now add a security resource group named marketing.9to5, and assign it a security policy which allows READ and EXECUTE access between the hours of 9AM and 5PM. Because it is prefixed with the name of the marketing resource group, the marketing.9to5 resource group inherits the security policy of marketing, but restricts access to between the hours of 9AM and 5PM. You can then add new data sources with the marketing.9to5 prefix (which inherit the security policies of both the marketing and the marketing.9to5 security resource groups) as follows:

marketing.9to5.anotherWebService
marketing.9to5.sybaseDB

To Define a Security Resource Group

Perform the following steps to define a Liquid Data security resource group:

  1. Start the Administration Console (for details, see Starting the Administration Console).
  2. In the left pane of the Administration Console, expand the node for your domain and click the Liquid Data node.
  3. Click the Security tab on the Liquid Data console.

    4. Figure 19-4 Security Tab of Liquid Data Administration Console

    Security Tab of Liquid Data Administration Console


     
  4. Enter a name for the security resource group and click Define Policy.
  5. Assign a security policy to the resource group. For details, see Assigning Security Policies to Liquid Data Objects.

When you go back to the Security tab, you will see the new security group. You can now create objects with the security resource group prefix and they will inherit the security policy defined for the security resource group.

 

Assigning Security Policies to Liquid Data Objects

You can assign a security policy to any Liquid Data object, including data sources, custom functions, repository objects, and stored queries. The security policies you assign are similar to ones you can assign to WebLogic Server objects. For details on setting up WebLogic Server security, see Managing WebLogic Security in the WebLogic Server documentation.

This section describes the security policies and provides a general procedure for defining security policy. The following subsections are included:

Security Policy Methods (Access Levels)

You can assign the following access levels in security policies:

Table 19-5 Security Policy Access Levels for Liquid Data Resources 

Method (Access Level)

Description

All

Allows read, modify, and execute access to the object.

Read Configuration

Browse or view the contents of an item in the Liquid Data node of the WebLogic Administration Console. You can not necessarily see it in the Data View Builder or use it in a query.

Modify Configuration

In the Administration Console you can create, modify, rename, or delete files or directories, or upload items to the directory. This level also implies read access.

Execute Query

Allows execute permission on the object in the Data View Builder and use it in a query or Data View.

Whether a user can actually execute a query (either stored or ad hoc) is determined dynamically at runtime based on whether a user has execute access to all of the resources the query requires.

ConfigureCacheAPIAccess

The ability to access the purgeCache APIs. Only available on the query results cache. For details, see Configuring the Query Results Cache


 

Note: If an attribute is set for a particular configuration that setting will take precedence over the All access level setting for that configuration. For example if All is true but Execute Query is set to No, you would not be able to execute a query on that object.

The security policy you define ensures that only authorized users and groups can perform the following:

For the procedure to set a security policy, see To Assign a Security Policy to an Object.

Conditions for the Security Policies

When you build a security policy for an object, you must specify a set of conditions for the policy. The Liquid Data server evaluates the conditions at runtime and grants access to the resource if the conditions are met. You can specify security policies that limit access based the following conditions:

The conditions allow you to restrict access to any users, groups, or roles you specify. It also provides the ability to restrict access to a given time period of the day or to when the server is running in development mode.

Understanding the AND and OR Condition Logic

When you configure a security policy, you can specify the operator that controls the logic between conditions. The values for the logical operator can be either AND or OR. The AND operator indicates that both conditions (before and after the AND operator) must be true for the condition to be satisfied. The OR operator indicate that either one or the other (or both) condition must be true for the condition to be satisfied.

By moving the conditions up and down in the Policy Statement pane and changing the logical operator between AND and OR, you can create complex and robust policies that are evaluated dynamically at runtime.

To change the logic for a condition from AND to OR (or vice versa), select the condition and click the Change button, as shown in Figure 19-6.

Figure 19-6 Specifying Conditions With a Policy Statement

Specifying Conditions With a Policy Statement


 

To Assign a Security Policy to an Object

Perform the following general steps to assign a security policy to an object. Depending on the object, the steps might vary slightly.

  1. Start the Administration Console (for details, see Starting the Administration Console).
  2. In the left pane of the Administration Console, expand the node for your domain and click the Liquid Data node.
  3. Navigate to the Liquid Data object to which you want to apply a security policy. For example, if you are adding a security policy to a stored query, navigate to the Stored Queries tab.
  4. Click Define Security Policy or Edit Security Policy on the object to which you want to assign security. If the object already has a policy defined, the link is labeled "Edit Security Policy"; if the object has no defined policy, the link is labeled "Define Security Policy".

    5. Figure 19-7 Security Policy configuration screen

    Security Policy configuration screen


     
  5. In the Methods drop-down list, select one of the options. For a description of the options, see Security Policy Methods (Access Levels).
  6. For the Policy Condition, select a condition and click Add. For examples of these screens, see Figure 19-8 and Figure 19-9.

    7. Figure 19-8 Security Policy Time Constraints screen

    Security Policy Time Constraints screen


     

    Figure 19-9 Security Policy Users screen

    Security Policy Users screen


     

Note: You must enter the name for the User, Group, and Role screens exactly as they are defined in WebLogic Server, including capitalization. You can add any name, even ones with which there is no user, group, or role associated.

  1. If you are adding a user condition, enter the name of the user and click OK. If you are adding a group condition, enter the name of the group and click OK. If you are adding the name of a role, click the name of the role and click OK. If you are setting controls on access times, enter the beginning and end times and click OK.
  2. Repeat the previous two steps as necessary to add the conditions you require.
  3. In the Policy Statement section, modify the policy as desired by selecting conditions and moving them up, down, or changing the logic from AND to OR. For details, see Understanding the AND and OR Condition Logic.
  4. Note the inherited policies for the object. These are displayed for reference only; you cannot change them.
  5. When you are satisfied with your security policy, click Apply.

 

Integrating Liquid Data Security with Other BEA Software

This section describes how to integrate Liquid Data security with other BEA software. It contains the following sections:

In addition to Liquid Data security tasks, integration with these components might involve other security tasks required by these components. For more information, see the documentation associated with the software with which you want to integrate.

Web Services and Liquid Data Security

A WebLogic Server web service is a proxy for the client, so the security or subject context is determined by the client connection. For more information, see Configuring Security in Programming Web Services in the WebLogic Server documentation.

WebLogic Integration

WebLogic Integration uses WebLogic Server security to protect access to WebLogic Integration business processes and other resources. User access is determined by the roles to which the user is assigned. The WebLogic Administration Console is used to define users, organizations, and roles, and also to map roles to groups in WebLogic Server security. For more information, see Using WebLogic Integration Security in Deploying Solutions in the WebLogic Integration documentation.

Application Integration and Liquid Data Security

For information about Application Integration security, see Defining an Application View and Using Application Views by Writing Custom Code in Using Application Integration in the WebLogic Integration documentation.

WebLogic Portal and Liquid Data Security

When authenticating users with WebLogic Portal, WebLogic Portal passes the security credentials to Liquid Data. Once the security credentials are passed to Liquid Data, Liquid Data uses its security mechanism to enforce any security policies configured in the Liquid Data domain.

If you want to use the WebLogic Portal security mechanisms as the entry point for user security when Liquid Data and WebLogic Portal are running in separate domains, you can set up your Liquid Data and WebLogic Portal environments as follows:

There are also other ways of setting up security when Liquid Data and WebLogic Portal are in separate domains. For example, you can create a default user (or several default users) on the Liquid Data domain and then map Portal users to the default user(s). For more information about WebLogic Portal security, see the WebLogic Portal documentation.

If Liquid Data and WebLogic Portal are running in the same domain, the Liquid Data security works the same as in any other domain.

WebLogic Workshop and Liquid Data Security

WebLogic Workshop is a development environment, and developers might need to use the Run As command to test certain security configurations in Workshop. For information about WebLogic Workshop security, see WebLogic Workshop Security Overview in the WebLogic Workshop documentation.

 

Skip navigation bar  Back to Top Previous Next