Skip navigation.
Downloads | Product Documentation | Support

Administration Guide

# 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

- Defining Liquid Data Roles and Groups
- Creating Liquid Data Security Resource Groups
- Configuring Security Policies on Liquid Data Objects

- Initializing Liquid Data Security
- Defining Liquid Data Security Resource Groups
- Assigning Security Policies to Liquid Data Objects
- Integrating Liquid Data Security with Other BEA Software

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

- Can access a particular object
- Has read/write/execute permissions on the object or a subset of those permissions

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:

- Setting up security roles, groups, and users
- Configuring security policies for access to Liquid Data objects

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.

- For details of the WebLogic Server security infrastructure, see Managing WebLogic Securityin the WebLogic Server documentation.
- For details of how you can apply a security policy to a WebLogic Server resource, see Securing WebLogic Resources in the WebLogic Server documentation.

## 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
- Using Liquid Data Pre-Defined Security Roles and Groups
- Manually Creating Liquid Data Groups and Roles

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

- LDAdmin Role
- LDConsole Role
- LDAdministrators Group
- LDConsoleUsers Group

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.

- For details of the WebLogic Server security infrastructure, see Managing WebLogic Securityin the WebLogic Server documentation.
- For details of how you can apply a security policy to a WebLogic Server resource, see Securing WebLogic Resources in the WebLogic Server documentation.

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

- For relational database data sources, you define data access security by configuring the database connection pool in the Administration Console and specify security information. For more information, see Creating a JDBC Connection Pool and Securing WebLogic Resources in the WebLogic Server documentation.
- For application view data sources, you define data access security by:

- Configuring connection parameters on the Configure Connection Parameters page when you configure an application view using the Application View Console. For more information, see Defining an Application View Using the WebLogic Integration Application View Console.
- Configuring the application pool username and password in the Administration Console, as described in Configuring an Application View Data Source Description.

- For data views used as data sources, access is determined by the security policy associated with the underlying query and data sources, as well as the security policy set on the data view description.

### 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
- Setting Up Liquid Data Administrator Users
- Setting Up Liquid Data Console Users

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

- The Administration Console includes the Liquid Data node for your domain.
- The following groups exist in the domain:

- LDAdministrators (granted the LDAdmin Role)
- LDConsoleUsers`` (granted the LDConsole Role)

- The following roles exist in the domain:

- LDAdmin
- LDConsole

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

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

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.

Figure 19-4 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)
- Conditions for the Security Policies
- To Assign a Security Policy to an Object

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

- Access and execute a query. Liquid Data verifies user or group access, based on the security policy configured, before executing the query.
- Access specific data source elements (such as particular tables in a database, service calls in an application view, or a web service) for ad-hoc queries or custom functions. Liquid Data verifies user or group access to selected data source elements before executing the ad-hoc query.

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:

- User name
- Member of group
- Role granted
- Hours of access
- When server is in development mode

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

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

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

Figure 19-8 Security Policy Time Constraints screen

Figure 19-9 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:

- Web Services and Liquid Data Security
- WebLogic Integration
- Application Integration and Liquid Data Security
- WebLogic Portal and Liquid Data Security
- WebLogic Workshop and Liquid Data Security

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:

- For a WebLogic Portal domain to communicate with a separate Liquid Data server domain, both domains must be configured as trusted domains.
- Create a user with the same name in the WebLogic Portal domain and in the Liquid Data domain (the password need not be the same). This user must be authenticated in the portal domain and the credential is then passed to the Liquid Data domain before query execution (based on the security policies of the objects the query is requesting).

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.