> Administration Guide > Securing ALDSP Resources

Administration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Securing ALDSP Resources

ALDSP 3.0 provides two types of security:

This chapter explains how you can configure and manage runtime security and access control for different users through the ALDSP Administration Console. It contains the following sections:

 

Introduction to ALDSP Security

To work with ALDSP security features, you must first define and create users who will access the ALDSP Administration Console. For more information about creating users, refer to Create Users in WebLogic Server Administration Console Online Help.

ALDSP 3.2 provides enhanced security support. See the ALDSP 3.2 New Features Supplement.

To secure ALDSP artifacts you can create runtime security policies. ALDSP artifacts or resources include dataspaces, services, operations, library procedures, and data elements.

For more information on runtime security policies, refer to Understanding Runtime Security Policies

After creating users in an ALDSP-enabled WebLogic Server domain, you can control administrative access of these users by applying administrative access control policies. Access control on ALDSP Administration Console is based on user entitlements. Entitlements are assigned to users by a domain user, who is a super user for a particular domain. A domain user is created when you create an ALDSP domain and specify the user name and password for it.

For more information on administrative access control, refer to Working with Administrative Access Control Policies.

 

Understanding Runtime Security Policies

The runtime security feature enables you to configure access to resources such as dataspaces, data services, operations, and data elements. For a secured resource, a requesting client must meet the condition of the runtime security policy applicable to that resource, whether accessing the resource through the typed mediator API, an ad hoc query, or any data access interface. ALDSP exposes its deployed artifacts as resources that can be secured through runtime security policies.

For example, you can control access to an entire ALDSP dataspace or just to a credit card number element within Customer_Order.ds.

When a request comes to a running ALDSP instance for a secured resource, ALDSP passes an identifier for the resource to WebLogic Server. WebLogic Server, in turn, passes the resource identifier, user name, and other context information to the authorization provider, such as XACMLAuthorizer. The provider evaluates the policy that applies to the resource. As a result of the evaluation, access to the resource is either permitted or blocked.

If the user does not satisfy the requirements of an element-level policy, the element is redacted from the result object, and therefore does not appear.

Figure 5-1 Data Redaction

Data Redaction

Note: By default, WebLogic Server security uses the XACML Authorization Provider. Other authenticators can use any external resource necessary to implement the policy evaluation.

Definition of a Securable Resource

A securable resource is an ALDSP artifact, such as a data service, operation, or element, to which you can apply a runtime security policy. The resources you can protect using runtime security include:

After you secure individual resources, you can enable or disable security for the dataspace. Security policies are inherited. This means that security enabled at the dataspace level applies to all data services, operations, and elements within the dataspace. However, if several policies apply to a particular resource, the more specific policy prevails. For example, a policy on an element supercedes a policy for the data service.

The hierarchy of ALDSP artifacts is as follows:

Dataspace

    Data Service

             Operations

                     Element

Figure 5-2 illustrates the securable resources in an ALDSP dataspace.

Figure 5-2 Securable Resources

Securable Resources

Allowing Anonymous Access

At the dataspace level, you can enable anonymous access by creating a policy. If you apply this policy, all users, including unauthenticated users, can access resources by default. For more information on creating runtime policies at the dataspace level, refer to Configuring Dataspace-Level Security.

The anonymous access policy works only with the WebLogic Authorization provider. The ALDSP security policies are intended to work with the default WebLogic Authorization provider. If you are using another authorization provider, you will need to create policies using the facilities of the other provider. For more information, see WebLogic Authorization Provider: Provider Specific in the Administration Console Online Help.

The Security Configurations tab on ALDSP Administration Console provides the configurable runtime security policies. Setting up runtime security in ALDSP Administration Console involves the following tasks:

ALDSP directly supports runtime security policies for its resources. The WebLogic Platform supports extensive security features that can be applied to your implementation as well, including encryption-based, transport-level security. For runtime security configuration, ALDSP provides the following policies, called predicates, in ALDSP Administration Console:

The security policies in the ALDSP Administration Console are similar to the conditions used by WebLogic Server security. For more information on WebLogic Server security policies and conditions, refer to Securing WebLogic Resources Using Roles and Policiesin the WebLogic Server documentation.

In addition to creating runtime security policies, you can create service accounts to map security configurations of external data sources such as web services and Java functions. This feature ensures secure storage of the credentials of external data sources and allows runtime identity mapping.

 

Creating and Applying Runtime Security Policies

Before you start creating and applying runtime policies, make sure that the Enable Access Control checkbox in the General tab is selected, as shown in Figure 5-3. This activates the security policy configurations. If access control is not selected, then security is not enabled for your dataspace. The General tab is available only at the dataspace level.

Figure 5-3 General Tab

General Tab

To enable access control:

  1. Select the Security Configurations tab and the dataspace from the navigation pane.
  2. Acquire the lock by clicking Lock & Edit.
  3. Click the General tab.
  4. Select Enable Access Control checkbox.
  5. To enable JDBC metadata access, select Enable JDBC Metadata Access Control.
  6. Click Save > Activate Changes.

The steps to create and apply runtime security policy for a dataspace, data service, and operations are the same. However, you must make sure that you select the ALDSP resource from the navigation pane. To create and apply the runtime security policy:

  1. Select the Security Configuration category.
  2. Click the Policy tab to start creating runtime policies for a dataspace, as shown in Figure 5-4.
    3. Figure 5-4 Security Configurations: Policy Tab


    Security Configurations: Policy Tab

  3. Click Add Conditions on the Policy tab. The Choose a Predicate page is displayed.
  4. Select the predicate from the Predicate List drop down. For example, select User and click Next.
  5. The next page that appears, depends on the predicate you select. If you select User predicate, the page show in Figure 5-5 is displayed.
Note: If you select the User predicate, it implies that you are allowing a particular user to access the dataspace. Make sure that this user is authenticated by WebLogic Server.
  1. Specify the user name in the User Argument Name field, for example User A, and click Add. This adds the argument to the text box adjacent to the Remove button.
    2. Figure 5-5 User Predicate Arguments Page


    User Predicate Arguments Page

  2. Click Finish. This adds the policy to the policy conditions applied to the dataspace.

 

Configuring Dataspace-Level Security

You can configure runtime policies that would ensure access to users who are assigned entitlements to access the entire dataspace. At the dataspace level, the Security Configuration tab provides the following tabs:

  1. General: This tab provides the options to enable secured access to ALDSP resources and also to JDBC metadata. To access these options, click Lock & Edit to acquire the lock. It includes the following options:
Note: If an access policy is time-dependent or is changed and the metadata access control option is enabled, you may not be able to access the tables and procedures that had been listed.
  1. Policy: This tab allows you to edit policies if the default authorization provider, XACMLAuthorizer, is used. It provides the following information:
  1. XQuery Functions for Security: An XQuery function for security 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. For more information, refer to Working with XQuery Functions for Security.
  2. Service Accounts Configuration: Service accounts represent a mapping of user credentials between an ALDSP user and the user of an external data source, such as a web service or Java function. This mapping is stored as a part of the dataspace configuration and ensures secure storage of external identity credentials. You can associate service accounts with a number of external data sources to perform runtime identity mapping. For more information, refer to Understanding and Using Service Accounts.

Working with XQuery Functions for Security

XQuery security functions allow data-driven security of ALDSP resources. At the dataspace level, you can create and maintain XQuery functions to ensure that data elements are returned only when the conditions are met. However, to associate these functions to data service elements, go to the data service and specify the element for which the function applies.

Note: If both a standard security policy and an XQuery function applies to a given data element, the results of both policy evaluations must be true for access to be permitted (logical and is applied to the results).

Applying data-driven security policies involves the following steps:

  1. Identify the element as a secured element. (For more information, see Configuring Data Element-level Security.)
  2. Create a security XQuery function to define the data-level security. (For more information, see Creating an XQuery Function for Security.)
  3. Apply a security XQuery function to the data element. (For more information, see Applying an XQuery Function for Security.)

Creating an XQuery Function for Security

You can create one or more XQuery functions to apply to data elements within a dataspace.

To create an XQuery function for security:

  1. Click Security Configurations tab and select the dataspace in the Navigation tree.
  2. Click Lock & Edit to acquire the lock and then select the XQuery Functions for Security tab.
    3. Figure 5-6 Security XQuery Functions


    Security XQuery Functions

  3. Add the XQuery function body in the text area of the tab, as shown in Figure 5-6. The following code sample is used in this illustration:
    4. import schema namespace t1 = 'ld:DataServices/CUSTOMER_ORDER' at 
    	'ld:DataServices/Schema/CUSTOMER_ORDER.xsd';
    declare namespace f1 = "ld:CUSTOMER_ORDER";
    declare function f1:secureOrders($order as
    		element(f1:CUSTOMER_ORDER)) as xs:boolean {
    if (fn-bea:is-access-allowed("CUSTOMER_ORDER/LimitAccess",
    		"ld:CUSTOMER_ORDER.ds")) then
    	fn:true()
    else if ($order/TotalOrderAmount lt
    	(fn-bea:get-property("total_order_amount", "1000000") cast as
    			xs:decimal)) then
    		fn:true()
    	else
    		fn:false()
    };

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 an element name and a resource identifier.

ALDSP provides the following additional convenience functions for security purposes:

Note: For details on creating XQuery functions, see the XQuery and XQSE Developer’s Guide.
  1. Click Compile and ensure that the function compiles successfully.
  2. Click Save > Activate Changes to store the XQuery function.
Note: A security XQuery function must be applied to a data element for it to take effect. For more information, see Applying an XQuery Function for Security on page 5-13. 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 should be qualified by a namespace URI.

Applying an XQuery Function for Security

You can use XQuery functions for security to control access to data elements. After you define the XQuery function for security, as described in Creating an XQuery Function for Security on page 5-11, you must apply the function to the corresponding data element for it to take effect. In addition, you define policies for securing the data elements, which provide additional security along with the XQuery functions for security. For more information, refer to Configuring Data Element-level Security.

Note: ALDSP 3.2 provides support for data redaction behavior for data elements. See “Encryption-based Data Redaction” in the ALDSP 3.2 New Features Supplement.

To make any changes to the security configurations of a data element, you must first acquire the lock by clicking Lock & Edit. To apply the XQuery function for security to a data element:

  1. Select the Security Configuration tab from the navigation pane and then click the data service associated with the data element that you need to secure.
  2. Click the Secured Elements tab and select the checkbox next to the data element to which you want to apply a custom function.
  3. Click Save and then click Activate Changes. This data element is now visible under the data service in the navigation tree.
  4. Select the data element from the navigation tree and click the Secured Elements Configuration tab. This tab allows you to specify the qualified function name and namespace URI for the XQuery function that you want to associate with the data element, as shown in Figure 5-7.
    5. Figure 5-7 Applying XQuery Functions for Security


    Applying XQuery Functions for Security

  5. If you want to specify a default value for the element or attribute, then select the User Default Value checkbox and specify the default value in the Default Value box.

    6. This option allows you to assign a constant value for the element or attribute. However, it supports only primitive types, so you cannot have a default value for complex types.

    Note: If you select this check box, then it is mandatory to specify the default value for the resource.
  6. Specify the namespace URI and local name of the XQuery function that you have created.
  7. Click Add > Save > Activate Changes. This completes the association of the data element with the XQuery function for security.

Understanding and Using Service Accounts

Service accounts provide the option to store user credentials for external data sources. It provides a mapping between the local WebLogic user and a remote external data source user by configuring the user credentials within the ALDSP Administration Console.

You can configure service accounts for web services and Java functions. For JDBC identity mapping, ALDSP depends on WebLogic Server 9.2 and 10.0 built-in support.

Service accounts provide different types of mappings, which include:

Note: After you create and define the type of a service account, you cannot change it. If you have to change a service account type, delete the account and create a new one.

Creating a Service Account

To create a service account:

  1. Click the Security Configurations tab in the category list, select the dataspace in the navigation tree, and click the Service Accounts tab in the workspace content area.
  2. Click Lock & Edit to acquire the lock.
  3. Click New. This opens the Create a New Service Account page, as shown in Figure 5-8.
  4. On this page, specify the following details:
Note: Based on the selected resource type, the Next button is enabled.
  1. If you select the resource type as Static:
    1. Click Next.
    2. On the next page, specify the user name and password for that account and click Finish, as shown in Figure 5-9.
      3. Figure 5-9 Creating a Static Service Account


      Creating a Static Service Account

  2. If you select the resource type as Mapping and click Next, a new page is displayed, as shown in Figure 5-10.
    3. Figure 5-10 Creating a Service Account of the Mapping Type


    Creating a Service Account of the Mapping Type

    On this page, you can define the remote (external data source) users.

    1. Specify the remote user name and password in the Remote User Name and Password fields, respectively, of the Enter Authorized Remote User table.
    2. Click Add. This adds the users to the Remote Users table. Using the Remote Users table you can edit the password or delete a user, as required.
    3. Click Next after adding the remote users. The next page enables you map the local users to remote users, as shown in Figure 5-11.
      4. Figure 5-11 Local User to Remote Mapping


      Local User to Remote Mapping

    4. Specify the local user name in the Local User Name field and select the corresponding remote user from the Remote User Name list.
    5. Click Add. This creates the local to remote user mapping.
    6. To map all unauthenticated (anonymous) users to a particular remote user, click the Map Anonymous Requests checkbox and then choose the remote user from the drop-down list.
    7. In case you want to provide a default mapping for all authenticated user that do not have an explicit mapping to the remote user, click the Map Other Authenticated Requests checkbox and choose the remote user from the drop-down list.
    8. Click Finish.
  3. If you select the resource type as Identity Mapping and click Next, a page is displayed, as shown in Figure 5-11. This page is identical to the page displayed when you select Mapping as the resource type.

    4. On this page, you can define the authorized remote (external data source) users, and add them as authenticated external data source users.

    1. Specify the remote user name and password in the Remote User Name and Password fields, respectively, of the Enter Authorized Remote User table.
    2. Click Add. This adds the users to the Remote Users table. Using the Remote Users table you can edit the password or delete a user, as required.
    3. Click Next after adding the remote users. The next page enables you to map anonymous requests or other authenticated requests to remote users.
      4. Figure 5-12 Mapping Anonymous Requests or Other Authenticated Requests


      Mapping Anonymous Requests or Other Authenticated Requests

    4. To map all unauthenticated (anonymous) users to a particular remote user, click the Map Anonymous Requests checkbox and then choose the remote user from the drop-down list.
    5. In case you want to provide a default mapping for all authenticated user that do not have an explicit mapping to the remote user, click the Map Other Authenticated Requests checkbox and choose the remote user from the drop-down list.
    6. Click Finish. This creates a mapping between the defined external data source users and the identically-named authenticated ALDSP users.
  4. Click Activate Changes.

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 ALDSP artifacts, such as dataspaces, data services, and operations. 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 ALDSP Administration Console to configure your policies. In particular, resource identifiers already exist for ALDSP dataspaces, data services, and data service operations. 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 must 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 need to identify the element resources that need to be protected.

Note: The WebLogic security documentation provides details on how to connect another security authenticator to WebLogic Server. For more information, see WebLogic Authorization Provider in the Administration Console Online Help.

You can view the list of resource identifiers by exporting the access control resources from the ALDSP Administration Console.

To export the file:

  1. Select the dataspace in the navigation pane and select the General tab from the Security Configuration category.
  2. Click Lock & Edit and then click Export Access Control Resources if you want to export the current session values of the dataspace.
  3. If you want to export the core values, then click Export Access Control Resources without acquiring the lock.
  4. Save the text file.

    5. An example of a portion of the file follows: 

    <ld type="admin"><app>DOMAIN</app></ld>
    <ld type="admin"><app>ADMIN</app></ld>
    <ld type="admin"><app>MONITOR</app></ld>
    <ld type="admin"><app>BROWSER</app></ld>
    <ld type="admin"><app>ADMIN</app><ds>DSP_TEST</ds></ld>
    <ld type="admin"><app>MONITOR</app><ds>DSP_TEST</ds></ld>
    <ld type="admin"><app>BROWSER</app><ds>DSP_TEST</ds></ld>
    <ld type="app"><app>DSP_TEST</app></ld>
    <ld type="service"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds></ld>
    <ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}CREDIT_CARD:0</res></ld>
    <ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}createCREDIT_CARD:1</res></ld>
    <ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}deleteCREDIT_CARD:1</res></ld>
    <ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}updateCREDIT_CARD:1</res></ld>
    <ld type="service"><app>DSP_TEST</app><ds>ld:CUSTOMER.ds</ds></ld>

The format of a resource identifier is shown in Figure 5-13.

Figure 5-13 Resource Identifier Format

Resource Identifier Format

The type can be admin, service, or function. The resource can be any of the following:

These are generated when you select an element in the Secured Element tab of the ALDSP Administration Console.

 

Configuring Data Service and Operation-Level Security

A data service has several operations, including one or more read, create, update, delete, navigation, and library operations. The security policies that you apply at the data service level apply to data service operations and data elements. You can also select the data elements that you want to secure at the data service level.

Operation-level security policies enable you to control:

Note: Make sure that you 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 another data service, the policy is not evaluated against the caller. For more information, refer to Creating and Configuring Security Policies for Operations.
Note: Data service operations are identified by name and number of parameters for setting security configurations. If you modify the number of parameters, you will need to reconfigure the security settings for the operation.

Creating Data Service Runtime Security Policies

The steps to create the security policy at the data service and operation level are the same as the dataspace level. Refer to Creating and Applying Runtime Security Policies for details.

Note: ALDSP 3.2 provides enhanced security support. See the ALDSP 3.2 New Features Supplement.

At the data service level, you can select all the data elements in a data service by selecting the top-level element (Customers in Figure 5-14) or individual data elements that you want to secure using the Secured Elements tab.

For example, if you create an XQuery function for security and you want to associate it with a data element, you can select the data element from the Secured Elements tab and then configure the data-element level security. (For more information about XQuery function for security, refer to Working with XQuery Functions for Security.)

Note: You should only secure the root element of a data service if you are confident that none of the elements used by read functions in the service must return a value. Since a secured element does not return a value, a schema which requires that one or more values be returned will fail with a runtime error. Alternatively, you can modify the schema so that elements are optionally returned.

To select the data element to be secured:

  1. Acquire the lock and select the data service.
  2. Select the Secured Elements tab, as shown in Figure 5-14.
  3. Select the data element that you want to configure for security.
  4. Click Save > Activate Changes. Notice that the selected element is now included in the navigation tree under the data service, as shown in Figure 5-14.
    5. Figure 5-14 Secured Data Element in the Navigation Tree


    Secured Data Element in the Navigation Tree

To apply security policy to the data element, select the element from the navigation tree. You can also select the secured element using the Secured Elements tab. For more information, refer to Configuring Data Element-level Security.

Creating and Configuring Security Policies for Operations

To set runtime security policy for an operation:

  1. Select the operation from the navigation tree and click the Function Configuration tab.
  2. Select the Always Secured checkbox and click Save as shown in Figure 5-15.
    3. Figure 5-15 Function Configuration Tab


    Function Configuration Tab

This setting ensures that every time this operation is accessed, the runtime policy is adhered to. Consider the following example:

In this scenario, if you access fn1 using user1, then access will be denied because the runtime security policy configuration does not allow user1 to access fn2.

If you do not select the Always Secured check box for fn2, then you will be able to access fn1 if using either user1 or user2 because the system will check the security policy for fn1 only and not fn2.

Configuring Data Element-level Security

Element-level security associates a security policy with a data element for the Return type within a data service. If the policy condition is not met, the corresponding data is not included in the result.

When configuring element-level security, you first identify the element as a securable resource, then set a policy on the resource.

The data element security policy can be configured using the steps described in Creating and Applying Runtime Security Policies.

To associate an XQuery function for security with a corresponding data element, select the Secured Elements Configuration tab and follow the steps mentioned in Applying an XQuery Function for Security.

Note: Element-level security is only applied when all of the following conditions are met:

Additional Data Element Security Considerations

To ensure the security of elements, you need to manage and layer data services properly. This means being careful not to create insecure holes in the layers and not depending on security settings for data services which are not being directly invoked by the client.

Note: Secured elements, in general, should never offer public read or navigate functions that accept a secured element value as an input argument as this can permit guessing-style attacks to reveal otherwise secure data.

Securing Native Web Services

You can set the security policies for native web services using the Basic Auth Required property in the Eclipse IDE. You can create runtime security policies for a native web service and then set this property to true. This applies the security policy for the native web service. For more information about the Basic Auth Required property, refer to the Add Security Resources to Data Services topic in the Designing Logical Data Services section of the Data Services Developer’s Guide.

The Service Explorer in ALDSP Administration Console allows you to check if the Basic Auth Required property is set to true or false.

To view information about this property in the Service Explorer:

  1. Click the Service Explorer category. The General tab is displayed as shown in Figure 5-16.
    2. Figure 5-16 Basic Auth Required Property Information in Service Explorer


    Basic Auth Required Property Information in Service Explorer

  2. Select the native web service from the navigation tree. In this case, the Basic Auth Required property is set to true. This implies that some security policy is applied to SERVICE_CASE.ws, which the native web service.

Creating Security Policies for User-Defined Security Resources

User-defined security resources are created in the Eclipse IDE Property Editor, as shown in Figure 5-17.

Figure 5-17 ALDSP IDE Property Editor: User-Defined Security Resources

ALDSP IDE Property Editor: User-Defined Security Resources

For more information about setting the security resource values, refer to Declare a Security Resource in Data Services Developer’s Guide.

After you assign a value to the security resource, you can create runtime security policies for the user-defined security resource. In the preceding figure, ordertime is the value of the security resource. After you deploy the dataspace, this resource is displayed in ALDSP Administration Console. Figure 5-18 shows the ordertime security resource in the navigation tree for the customerorder data service.

Figure 5-18 Creating Runtime Security Policy for a User-Defined Security Resource

Creating Runtime Security Policy for a User-Defined Security Resource

You can create a runtime security policy for the ordertime security resource using the console.

 

Working with Administrative Access Control Policies

Administrative roles require entitlements to access ALDSP Administration Console. These entitlements can be assigned through the Administrative Access Control category, as shown in Figure 5-19.

Figure 5-19 Administrative Access Control Tab

Administrative Access Control Tab

A domain user, who is the super user for the console, assigns entitlements to users. In addition to the domain entitlement, other predefined entitlements are admin, monitor, and browser, which allow access to information for different categories and resources. The hierarchical structure of the entitlements is as follows:

Domain

  Admin

     Monitor

       Browser

This hierarchy implies that the domain entitlement allows you to perform all the tasks on ALDSP Administration Console, depending on whether the domain entitlement is for all the dataspaces within a domain or a particular dataspace. However, other entitlements cannot perform all the tasks that can be performed by a user with domain entitlement.

For example, you can set the administrative access control policies only if you have domain entitlement. Similarly, the admin entitlement allows you to perform more tasks on a dataspace than monitor or browser entitlements.

Note: Entitlements can be assigned at the dataspace level or for all the dataspaces. For example, for User A, you can assign admin entitlement for DS1, monitor entitlement for DS2, and browser entitlement for DS3. Alternatively, you can assign the Admin entitlement for all the dataspaces within the domain to User A. For more information, refer to Assigning Entitlements.

A default domain user is created on WebLogic Server when you create the ALDSP domain. There can be more than one domain user for the console and one domain user can create other domain users.

Note:

By default, an Admin role is created for a domain user in ALDSP Administration Console which is mapped from WebLogic Server Administrator role, as shown in Figure 5-19.

Table 5-1 lists the tasks that can be performed by a user for each entitlement.

Table 5-1 Tasks Allowed for Entitlements  
Entitlement
Categories and Resources Available
Domain
The domain user for a dataspace can perform all the tasks on the ALDSP Administration Console. Some of the most important tasks that a domain user can perform include the following:
  • Creating, deploying, and deleting dataspaces
  • Creating users with domain, admin, monitor, browser entitlements
  • Editing and updating configurations
  • Acquiring lock from a user forcibly
  • Viewing all tabs in the category list, including the Administrative Access Control tab
  • Configuring auditing options
  • Manage data cache

Note: Only a domain user can acquire a lock forcibly from another user, regardless of the user entitlement. This means that the one domain user can forcibly acquire the lock from another domain user also.
Admin
Most of the information available to an admin user for a dataspace is the same as the domain user. However, an admin user cannot create or delete dataspaces and cannot assign entitlements. Therefore, when you log into the console with admin entitlement, then the Administrative Access Control tab will not be available.
Monitor
A monitor for a dataspace cannot make any changes in the ALDSP Administration Console. Therefore, the change center is disabled for the dataspace for which the user has monitor entitlements. The System Administration tab for a monitor user does not provide any options. A monitor user can view the following on the console:
  • Data cache, queries and updates available through the Operations category
  • For the dataspace, a monitor user can export the static mediator client jar file using the General tab.
Browser
A browser user has the least control over the ALDSP Administration Console. This user entitlement can only browse through the console. The change center is disabled for this user. However, like a monitor user, a browser user can also export the static mediator client JAR file.

Assigning Entitlements

Entitlements are created for users that are created on WebLogic Server 9.2 and can be managed through the WebLogic Server Administration Console.

To assign an entitlement:

  1. Log into the ALDSP Administration Console using the domain user name and password.
  2. Select the Administrative Access Control category.
  3. If you want to assign entitlement for a specific dataspace, then from the navigation tree, select the dataspace listed under the entitlement. For example, if you want to assign admin entitlement for dataspace DS1, then select DS1 listed under the Admin entitlement, as shown in Figure 5-20.
    4. Figure 5-20 Assigning Entitlement for a Dataspace


    Assigning Entitlement for a Dataspace

    You can also assign an entitlement to a user for all dataspaces within the domain. For example, if you want to assign the Admin entitlement for dataspaces DS1, DS2, and DS3 to a user, then select the Admin entitlement option. Similarly, you can assign, monitor and browser entitlements to a user for all dataspaces by selecting the Monitor or Browser option from the navigation tree.

Note: In this case, the Admin entitlement is selected for the dataspace DS1.
  1. Click Add Conditions on the Policy tab.
  2. Select the predicate as User and click Next.
Note: You can also select other options from the list of predicates. For more information, refer to Understanding Runtime Security Policies.
  1. Specify the user name for which you want to assign the admin entitlement and click Finish. This creates a user who has Admin entitlement for dataspace DS1.

A user views the category-list based on the entitlement assigned to that user for that dataspace. For example, User A with admin entitlement for DS1 can view the Security Configurations tab, however, if User A has monitor entitlement for DS2, then the Security Configuration tab for DS2 will not appear for User A.

Gaining Administrative Access After a System Lockout

Security policies configured for assigning Admin entitlement to a user may get deleted inadvertently. If that is the only Admin user entitlement for ALDSP Administration Console, then the Admin user is locked out of the console.

In this case, you can configure the com.bea.dsp.security.admin.bootstrap system property for WebLogic Server. This property allows you to specify a user name, who gains domain access rights. However, this property should only be used if the ALDSP Administration Console is locked due to some policy editing.

To configure this system property:

  1. Stop WebLogic Server.
  2. Open the setDomainEnv.cmd file located in: <aldsp_home>\samples\domains\aldsp\bin

    3. where <aldsp_home> is the home directory for ALDSP, for example, c:\bea\aldsp_3.0

  3. Edit this file to include the com.bea.dsp.security.admin.bootstrap system property. For example:
    4. set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES%
    -Dwlw.iterativeDev=%iterativeDevFlag%
    -Dwlw.testConsole=%testConsoleFlag%
    -Dwlw.logErrorsToConsole=%logErrorsToConsoleFlag%
    -Dcom.bea.dsp.security.admin.bootstrap=<username>

    where <username> is the place to specify the Admin user for ALDSP Administration Console.

Note: The user name specified in the com.bea.dsp.security.admin.bootstrap system property should be a user that has already been created using the WebLogic Server console.
  1. Save and close this file.
  2. Restart WebLogic Server.
  3. Log in to ALDSP Administration Console using this user name and then re-configure the Admin entitlement policies.

Taking Lock and Edit Capability

A domain user can take back the control of the lock from ALDSP Administration Console. The lock may need to be taken back from a user in cases where a user, such as an admin user, has acquired the lock but has not released it for a long period and another admin user needs to acquire the lock to modify configurations. One domain user can acquire the lock from another domain user also.

When lock is acquired by a user, the Take Lock & Edit option is enabled for the domain user as shown in Figure 5-21.

Figure 5-21 Take Lock & Edit Enabled in the Change Center

Take Lock & Edit Enabled in the Change Center

The domain user can click the Take Lock & Edit option from the change center to acquire the lock. In this case, the user whose lock is acquired will see the core configuration values on the console and the domain user or the other admin user will be able to view all the changes made by the other user using the pending changelist. For more information about pending changelist, refer to Pending Changelist on page 2-9.


  Back to Top       Previous  Next