Implementing Security

This section describes how to implement security in BEA Liquid Data for WebLogic^TM. It contains the following sections:

• Overview of Liquid Data Security

• Liquid Data Server Security Implementation Process

  • Initial Security Setup

  • Defining a Compatibility Security Realm

  • Enabling Liquid Data Secure Mode

  • Configuring Liquid Data Users

  • Configuring Liquid Data Groups

  • Assigning ACLs to Liquid Data Resources

• Integrating Liquid Data Security With BEA Other Software

 

---

Overview of Liquid Data Security

WebLogic Server provides the foundation for Liquid Data security. Liquid Data deployments can use the compatibility security features that WebLogic Server provides, including compatibility security realms, users and groups, Access Control Lists (ACLs) and permissions, the Secure Sockets Layer (SSL) protocol, authentication mechanisms, digital certificates, controlled access to resources, and so on.

The Administration Console provides configurable security mechanisms to prevent unauthorized access to core Liquid Data functionality. For complete information about using the Administration Console to manage WebLogic security, see Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.

By default, Liquid Data runs in non-secure mode. If you want to use WebLogic Server security features, you must explicitly enable Liquid Data security, as described in Enabling Liquid Data Secure Mode. Once enabled, system administrators use the Administration Console to manage Liquid Data security, which includes the following tasks:

• Setting up compatibility security realms, groups, and users

• Configuring access control lists (ACLs) for data sources and queries

Administration Console Security

The Administration Console requires a valid user login and selectively permits access to operations based on user roles. The  following table describes the permissions required to perform certain Liquid Data security management tasks in the Administration Console:

Table 16-1 Permissions Required for Administration Console Tasks  

Permission	Task
modify	Creating, modifying, and deleting data source descriptions. Creating, modifying, and deleting directories and files in the repository.
read	Viewing the contents of an item in the repository. Any user who can log into the Administration Console has read permission to view data source descriptions and the repository structure.

 

Data Access Security

If security is enabled for your Liquid Data Server installation, you must configure an ACL for the following resources: stored queries, data sources, repository directories, and file security. For more information, see Assigning ACLs to Liquid Data Resources.

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 ACL associated with the data source.

Stored Queries

For stored queries, access is determined by the ACL associated with the file name of the stored query. The ACL is assigned to the stored query in the Administration Console, as described in Assigning ACLs to Liquid Data Resources. 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 Query Engine for processing.

ACL names for stored queries use the following format:

LD.stored_queries.[subfolderName.]queryName

where

• stored_queries is the name of the folder in the server repository that contains stored queries.

• subfolderName is the name of the sub-folder that contains stored queries, if applicable.

• queryName is the file name of the stored query.

Ad Hoc Queries

For ad hoc queries, access is determined by the ACL associated with any data source(s) that the user attempts to use, as described in Data Source Security. The ACL 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 ACL associated with the data source description. The ACL 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 in the Properties, ACL, and Password fields. For  more information, see Creating a JDBC Connection Pool.

• 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 ACLs associated with the underlying query and data sources.

Repository Directory and File Security

Access to directories and files in the repository can be controlled by assigning ACLs to individual directories or files using the Administration Console. ACLs can be assigned to stored queries, data views, XML files, web service definitions, and custom functions. For more information, see Configuring Secure Access to Items in the Server Repository.

ACL names for folders and files in the server repository use the following format:

LD.folderName[.fileName]

where

• folderName is either the name of the folder to which to assign ACLs, or the name of the folder containing the item (folder or file) to which to assign ACLs.

• fileName is the name of the filename, if assigning ACLs to a particular file.

 

---

Liquid Data Server Security Implementation Process

To implement Liquid Data security, you perform the following tasks in the Administration Console:

1. Complete the initial security setup, as described in Initial Security Setup.

2. Set up a compatibility security realm, as described in Defining a Compatibility Security Realm.

3. Activate secure mode for Liquid Data according to the instructions in Enabling Liquid Data Secure Mode.

4. Add the LDAdmin group according to the instructions in Configuring Liquid Data Groups.

5. Add users associated with each of these groups according to the instructions in Configuring Liquid Data Users.

6. Assign ACLs to data sources, stored queries, and repository files and directories, according to the instructions in Assigning ACLs to Liquid Data Resources.

Initial Security Setup

When deploying Liquid Data in a domain, you need to perform the following steps to set up Liquid Data security:

1. Start the Administration Console on the domain on which you are deploying Liquid Data, logging in with the username/password you had created when the domain was initially configured.

2. In the left pane, click on domain_name->Compatibility Security->Users and add a new user (ldsystem).

3. Click on domain_name->Compatibility Security->Groups and add a new group (LDAdmin).

4. Add the ldsystem user to the LDAdmin group.

   Note: To add members to the LDAdmin group, you must add them as users, not as groups.

5. Add the ldsystem user to the Administrators group.

6. Click on domain_name->Compatibility Security->ACLs and add a new ACL (LD).

7. Add the following new permission attributes to the Liquid Data ACL: execute, read, and modify, and then add the Administrators group to the grantee list of permissions.

Defining a Compatibility Security Realm

A WebLogic Server compatibility security realm is a domain for a set of security features that provide access to ACLs, names of principals, and related security services. A realm provides a context in which the range of security operations and other security-related information governing Liquid Data users is defined. It determines how users are authenticated. The security features available for WebLogic Integration are built on the security functionality provided by WebLogic Server.

WebLogic Server provides the following types of compatibility security realms:

Table 16-2 Types of WebLogic Server Compatibility Security Realms  

Realm Type	Description
File realm	Stores all user and group data for the File realm in the fileRealm.properties file.
Caching realm	Works with the File realm, alternate security realms, or custom security realms to fulfill client requests with the proper authentication and authorization.
LDAP security realm	Provides authentication through a Lightweight Directory Access Protocol (LDAP) server. This server allows you to manage all the users for your organization in one place: the LDAP directory.
Windows NT security realm	Uses account information defined for a Windows NT domain to authenticate users and groups. You can view users and groups in the Windows NT Security realm through the Administration Console, but you must manage users and groups through the facilities provided by Windows NT.
UNIX security realm	Executes a small native program, wlauth, to look up users and groups and to authenticate users on the basis of their UNIX login names and passwords. Runs only on the Solaris and Linux platforms.
RDBMS security realm	BEA-provided custom security realm that stores users, groups and ACLs in a relational database.
Custom security realm	Custom built security realm that draws from an existing store of users such as directory server on the network. Requires an implementation of the weblogic.security.acl.AbstractListableRealm interface or the weblogic.security.acl.AbstractManageableRealm interface and uses the Administration Console to install this implementation.

 

The realm type you choose depends on the particular needs of your Liquid Data implementation. For example, the ld_samples domain uses a file realm defined in a filerealm.properties file.

To set up a compatibility security realm for Liquid Data, follow the detailed configuration instructions for your realm type in "Specifying a Security Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.

Enabling Liquid Data Secure Mode

By default, Liquid Data runs in non-secure mode. To implement Liquid Data security, you must explicitly enable the security mode in the General tab on the Liquid Data node in the Administration Console.

To enable Liquid Data security:

1. In the left pane of the Administration Console, expand the Servers node until the Liquid Data node is displayed.

2. Click the Liquid Data node.

3. In the right pane, click the Configuration tab.

4. Click the General tab.

   Figure 16-1 Enabling Liquid Data Security in the General Tab On the Liquid Data Node

   
    

5. On the General tab, select (check) Security Mode, as shown in the previous figure.

6. Click Apply.

Once security is enabled, you must explicitly define users, groups, and access control lists to Liquid Data resources. The Administration Console displays ACL hyperlinks that you can use to assign ACLs to associated resources. For more information, see:

• Configuring Liquid Data Users

• Configuring Liquid Data Groups

• Assigning ACLs to Liquid Data Resources

Configuring Liquid Data Users

You configure Liquid Data users using the Administration Console. At a minimum, you must define the ldsystem user according to the instructions in Initial Security Setup. For detailed instructions about configuring users, see "Defining Users in the Compatibility Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.

To configure Liquid Data users:

1. In the left pane of the Administration Console, click on the Compatibility Security node.

2. Click on the Users link.

   Figure 16-2 Configuring Liquid Data Users

   
    

3. On the Users page, in the Create a New User section, enter the name and password of the user you want to add.

4. Click Create.

Configuring Liquid Data Groups

This topic describes how to configure groups for Liquid Data. It contains the following sections:

• Group to Add for Liquid Data

• Configuring Groups

You configure Liquid Data groups using the Administration Console. For more information, see "Defining Groups in the Compatibility Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.

Group to Add for Liquid Data

For Liquid Data, you need to add the LDAdmin group, which allows Liquid Data administrators to perform the following tasks:

• Configure data sources

• Manage the server repository

• Assign ACLs

• Run queries

This group is added during Initial Security Setup. This group needs to be mapped to the Administrator group (and must never be unmapped from that group).

Configuring Groups

To configure Liquid Data groups:

1. In the left pane of the Administration Console, click on the Compatibility Security node.

2. Click on the Groups link.

   Figure 16-3 Configuring Liquid Data Groups

   
    

3. On the Groups page, click on the Create a New Group link.

   Figure 16-4 Configuring a Liquid Data Group

   
    

4. On the Group page, enter the group name and add any users or other groups to this group.

5. Click Apply.

Assigning ACLs to Liquid Data Resources

This topic describes how to assign ACLs to Liquid Data resources. It contains the following sections:

• Liquid Data Resources Requiring ACL Configuration

• Access Levels

• How ACLs Affect Access

At a minimum, you must define an LD ACL, add permission attributes to it (execute, read, and modify), and add the Administrators group to the grantee list of permissions.

If Liquid Data is running in secure mode, then you must assign ACLs to any Liquid Data resource to which you want users to have access. In secure mode, WebLogic Server automatically denies user access to any of these resources if they do not have an associated ACL.

Liquid Data Resources Requiring ACL Configuration

Liquid Data uses ACLs to control access to the following resources:

Table 16-3 Liquid Data Resources Requiring ACL Configuration  

Resource	Configuration Instructions
data source descriptions	Configuring Secure Access to Data Source Descriptions
directories and files in the server repository	Configuring Secure Access to Items in the Server Repository Includes stored queries, data views, XML data files and schema.
custom function descriptions	Configuring Secure Access to Custom Function Descriptions

 

Access Levels

You can assign the following access levels in an ACL:

Table 16-4 Access Levels ACL Formats for Liquid Data Resources  

Access Level	Task
execute	Run a stored query. For an ad hoc query, access is determined by whether the user has execute access to any data sources and custom functions associated with the ad hoc query.
modify	Create, modify, rename, or delete files or directories, or upload items to the directory. This level implies read access.
read	Browse or view the contents of an item, or download from the repository.

 

How ACLs Affect Access

ACLs ensure that only authorized users and groups can perform the following tasks:

• Access and execute a query. Liquid Data verifies user or group access, based on the ACL, 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.

You configure ACLs using the Administration Console. For more information, see "Defining ACLs in the Compatibility Realm" in Using Compatibility Security in Managing WebLogic Security in the WebLogic Server documentation.

Assigning Permissions, Users, and Groups to ACLs

In the Liquid Data configuration tabs in the Administration Console, if you click on the link to configure ACLs, the Administration Console displays the WebLogic Server ACL configuration page.

Figure 16-5 WebLogic Server ACL Configuration Page

 

To configure an ACL:

1. Do one of the following:

   • If you are creating a new ACL, click on Add a new Permission.

     or

   • If you are editing an existing ACL, click the name of the ACL that you want to edit.

   The Administration Console displays the Group tab.

   Figure 16-6 Group Tab for ACL Configuration

   
    

   Table 16-5 ACL Configuration Settings  

   Field	Description
   ACL	Unique name of this ACL.
   Permission	Access level for this ACL. One of the following values: read—Grants read access to the resource, allowing authorized users to view this resource but not make any changes. modify—Grants modify access to the resource, allowing authorized users to add, modify, delete, or otherwise change this resource. execute—Grants exec access to the resource, allowing authorized users to execute associated queries on the Liquid Data Server. For more information, see Access Levels.
   Users	List of users assigned to this ACL.
   Groups	List of groups assigned to this ACL.

   
    

2. Specify a permission level.

3. Specify one or more users associated with this permission. Click on the Users link to display the Users tab for currently configured users.

4. Specify one or more groups associated with this permission. Click on the Groups link to display the Groups tab for currently configured groups.

5. Click Apply.

   The Administration Console saves changes to this ACL.

 

---

Integrating Liquid Data Security With BEA Other Software

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

• Web Services and Liquid Data Security

• Application Integration and Liquid Data Security

• Business Process Management and Liquid Data Security

• B2B Integration and Liquid Data Security

• WebLogic Portal 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 realms to protect access to workflows and other resources. User access is determined by the roles to which the user is assigned. The WebLogic Integration Studio is used to define users, organizations, and roles, and also to map roles to groups in WebLogic Server security realms. 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.

Business Process Management and Liquid Data Security

The Business Process Management component of WebLogic Integration has its own security mechanisms for controlling access to workflows and other resources. You use the WebLogic Integration Studio to perform such tasks as defining users, groups, roles, organizations, and permission levels. For more information, see "Step 3: Configure BPM Security" in Using WebLogic Integration Security in Deploying Solutions in the WebLogic Integration documentation.

B2B Integration and Liquid Data Security

For information about B2B Integration security, see B2B Security in the WebLogic Integration documentation.

WebLogic Portal and Liquid Data Security

If you want to use the WebLogic Portal security mechanisms as the entry point for user security, you can either:

• Run Liquid Data in non-secure mode, as described in Enabling Liquid Data Secure Mode.

  or

• Create a user in WebLogic Portal and, in Liquid Data, grant that user complete permissions (read, modify, and execute) to all Liquid Data resources, according to the instructions in Assigning ACLs to Liquid Data Resources.

For more information about WebLogic Portal security, see Adding Security to a Portal in the WebLogic Portal Developer Guide and Administering Users and Groups in the WebLogic Portal Administration Guide.

WebLogic Workshop and Liquid Data Security

For information about WebLogic Workshop security, see Workshop Security Overview in the WebLogic Workshop documentation.