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:
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
For the procedure for defining security resources groups, see Defining Liquid Data Security Resource Groups.
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 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Now add a security resource group named
marketing.9to5, and assign it a security policy which allows
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:
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.
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.
The ability to access the
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.
For the procedure to set a security policy, see To Assign a Security Policy to an Object.
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.
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 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
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.
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.
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.
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 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.
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.
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.
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.