The Data Services Platform (ALDSP) leverages the security features of the underlying WebLogic platform. Specifically, it uses resource authorization to control access to ALDSP resources based on user identity or other information.
Note:
WebLogic Server must be running.
Objectives
After completing this lesson, you will be able to:
Enable application-level security.
Set function-level read and write access security.
Set element-level security.
Overview
ALDSP's security infrastructure extends WebLogic Server's security policies to include ALDSP objects such as data sources and stored queries, as well as security roles, groups, and users. These security policies allow ALDSP administrators to set up rules that dynamically determine whether a given user:
Can access a particular object.
Holds read/write/execute permissions on a ALDSP object or a subset of those permissions.
By default data services do not have any security policies configured. Therefore data is generally accessible unless a more restrictive policy for the information is configured. Security policies can apply at various levels of granularity, including:
Application level. The policy applies to all data services within the deployed ALDSP application.
Data service level. The policy applies to individual data services within the application.
Element level. A policy can apply to individual items of information within a return type, such as a salary node in a customer object. If blocked by insufficient credentials at this level, the rest of the returned information is provided without the blocked element.
Implementing ALDSP access control involves using the WebLogic Server Console to configure user groups and roles. You can then use the ALDSP Console to create policies for ALDSP, including data services and their functions.
16.1 Creating New User Accounts
The first step in creating data service security policies is to create user accounts and either assign the user account to a default group or configure a new group. There are 12 default authenticator groups.
Objectives
In this exercise, you will:
Open the WebLogic Server Console.
Create two user accounts that use a default user group.
View the user list.
Instructions
Open the WebLogic Server Console (http://localhost:7001/console/), using the following credentials:
User Name = weblogic
Password = weblogic
Choose Security Realms myrealm Users.
Figure 16-1 User Security
Select Configure New User.
Figure 16-2 Define User in Security Realm
Create a new user account by completing the following steps:
Enter Joe in the Name field.
Enter password in the Password field.
Enter password in the Confirm Password field.
Click Apply.
Repeat step 3 and step 4, entering Bob in the Name field (step 4a).
(Optional) Choose Security Realms myrealm Users to view the results.
Figure 16-3 New Users Added
16.2 Setting Application-Level Security
Application-level security applies to all data services within the deployed ALDSP domain, regardless of user permission or group. By default, when you turn on access control for an application, access to any of its resources is blocked, except for users who comply with policies configured for the resources.
Alternatively, by allowing default anonymous access, you can grant access to its resources by default. You can enable default anonymous access level by navigating to Application level General tab under Access Control (application Name General). In this case, a resource is restricted only if a more specific security policy for it exists; for example, a security policy at the data service function level.
Objectives
In this exercise, you will:
Use the AquaLogic Data Services Platform Console to enable application-level security.
Use WebLogic Workshop to test the security policy.
Instructions
In the ALDSP Console (http://localhost:7001/ldconsole/), using the + icon, expand the ldplatform directory.
Note:
If you click the ldplatform name, the Application List page opens. You do not want this page for this lesson.
Click Evaluation. The application's General page opens.
Select Check Access Control.
Click Apply.
Figure 16-4 Set General Security
Test the security policy by completing the following steps:
In WebLogic Workshop, open CustomerProfile.ds in Test View.
Select getCustomerProfile() from the Function drop-down list.
Enter CUSTOMER3 in the Parameters field.
Click Execute. The test should return an Access Denied error. With the current security settings, no one can access the application's functions. You must grant user access to read and write functions.
Figure 16-5 Access Denied
16.3 Granting User Access to Read Functions
ALDSP security policies can be set at the function level, which applies to specific functions within specific data services. Function-level security can be read and/or write permissions. A policy may include any number of restrictions; for example, limiting access based on the role of the user or on the time of access. Specifically, policies can be based on the following criteria:
User Name of the Caller. Creates a condition for a security policy based on a user name. For example, you might create a condition indicating that only the user John can access the Customer data service.
Caller is a Member of the Group. Creates a condition for a security policy based on a group.
Caller is Granted the Role. Creates a condition based on a security role. A security role is a special type of user group specifically for applying and managing common security needs of a group of users.
Hours of Access are Between. Creates a condition for a security policy based on a specified time period.
Server is in Development Mode. Creates a condition for a security policy based on whether the server is running in development mode.
Objectives
In this exercise, you will:
Use the ALDSP Console to grant Joe read access permissions, based on user name.
Use WebLogic Workshop to test the new security policy.
Instructions
In the ALDSP Console, open the CustomerProfile data service. (The data service is located in ldplatform\Evaluation\DataServices\CustomerManagement.)
Click the Security tab. The Security Policy tab opens.
Figure 16-6 Data Service-Level Security Policy
Click the Action Policy icon for the getCustomerProfile resource to open the Access Control Policy window.
Figure 16-7 Configure Security
Set read access for a specific user, by completing the following steps:
Select User name of the caller.
Click Add. The Users dialog box opens.
Enter Joe in the Name field.
Click Add.
Figure 16-8 Adding User
Click OK and move back to the Access Control Policy window.
Click Apply.
Login to the now-secure application, by completing the following steps:
In WebLogic Workshop, choose Tools Application Properties WebLogic Server.
Select Use Credentials Below.
Enter Joe and password in the Use Credentials Below fields.
Click OK.
Figure 16-9 Logging Into Secure Application
Test the security policy by completing the following steps:
Open CustomerProfile.ds in Test View.
Select getCustomerProfile() from the Function drop-down list.
Enter CUSTOMER3 in the Parameters field.
Click Execute. The test should permit access and return the requested data.
Click Edit, modify an item, and then click Submit. An error message will display because Joe is granted only read access.
16.4 Granting User Access to Write Functions
As noted in the previous exercise, security policies at the function level can allow either read and/or write permissions.
Objectives
In this exercise, you will:
Use the ALDSP Console to grant Joe write access permissions.
Use WebLogic Workshop to test the new security policy.
Instructions
In the ALDSP Console, open the CustomerProfile data service.
Select the Security tab. The Security Policy tab opens.
Click the Action Policy icon for the submit resource. The Access Control Policy window opens.
Set write access to a user, by completing the following steps:
Select User name of the caller.
Click Add.
Enter Joe in the Name field.
Click Add.
Click OK.
Click Apply.
Test the security policy, by completing the following steps:
In WebLogic Workshop, open CustomerProfile.ds in Test View. The file is located in DataServices\CustomerManagement.
Select getCustomerProfile() from the Function drop-down list.
Enter CUSTOMER3 in the Parameters field.
Click Execute. The test should permit access and return the specified results.
Click Edit. Because Joe is granted both read and write access, you can now edit the results.
16.5 Setting Element-Level Data Security
A policy can apply to individual items of information within a return type, such as a salary node in a customer object. If blocked by insufficient credentials at this level, the rest of the returned information is provided without the blocked element.
Objectives
In this exercise, you will:
Enable element-level security.
Set a security policy for specific elements.
Instructions
In the ALDSP Console, open the CustomerProfile data service.
Select the Security tab.
Set element-level security, by completing the following steps:
Select the Secured Elements tab.
Expand the CustomerProfile and customer+ nodes.
Select the checkbox for the ssn simple element.
Expand the orders ? and orders * nodes.
Select the checkbox for the order_line * complex element.
Click Apply.
Figure 16-10 Setting Element-Level Security
Return to the Security Policy tab for CustomerProfile. You should see two new resources: CustomerProfile/customer/ssn and CustomerProfile/customer/orders/order/order_line.
Figure 16-11 New Secured Element Resources
Set the security policy for the complex order_line element, by completing the following steps:
Return to the Security Policy tab for CustomerProfile.
Click the Action Policy icon for the CustomerProfile/customer/orders/order/order_line resource. The Access Control Policy window opens.
Select User name of the caller.
Click Add.
Enter Joe in the Name field.
Click Add.
Click OK.
Click Apply.
Set the security policy for the simple ssn element, by completing the following steps:
Click the Action Policy icon for the CustomerProfile/customer/ssn resource. The Access Control Policy window opens.
Select User name of the caller.
Click Add.
Enter Bob in the Name field.
Click Add.
Click OK.
Click Apply.
16.6 Testing Element-Level Security
At this point, element-level security policies are defined for both Bob and Joe. Testing the policy within WebLogic Workshop lets you determine what data results these two users will be able to access.
Objectives
In this exercise, you will:
Test the security policy for Bob and Joe.
Change the security policy for Bob and test the new security policy.
Instructions
Test element-level security for Joe, by completing the following steps:
In WebLogic Workshop, open CustomerProfile.ds in Test View.
Select getCustomerProfile() from the Function drop-down list.
Enter CUSTOMER3 in the Parameters field.
Click Execute. The test should permit access and return all results except SSN.
Click Edit, modify an order_line value, click Submit, and click OK. The specified change is submitted.
Click Execute to refresh the data set.
Verify that changes have been saved.
Test the element-level security policy for Bob, by completing the following steps:
Enter Bob and password in the Use Credentials Below fields.
Click OK.
Open CustomerProfile.ds in Test View.
Select getCustomerProfile(CustomerID) from the Function drop-down list.
Enter CUSTOMER3 in the Parameters field.
Click Execute. The test should fail. Although Bob can access the SSN element, he does not have read access to the getCustomerProfile() function.
Change the security policy for Bob, by completing the following steps:
In the ALDSP Console, open the CustomerProfile data service.
Select the Security tab.
Click the Action Policy icon for the getCustomerProfile resource. The Access Control Policy window opens.
Set read access for Bob, by completing the following steps:
- Select the caller's User name.Click Add.
- Enter Bob in the Name field. Click Add, then Ok.
- Click the "and User name of the caller" line, located in the Policy Statement section of the window.
- Click Change, which changes the line to an "or User name of the caller" condition.
- Click Apply.
Figure 16-12 Enabling read Access for Two Users
In WebLogic Workshop, test the getCustomerProfile() function again. This time, user Bob can view all elements except order_line information.
Try modifying data by clicking on Edit button and changing SSN. Submit changes by clicking on Submit button. An error message will display because Bob does not have write privileges.
Reset the application-level security, by completing the following steps:
Reset the WebLogic Workshop Tools Application Properties WebLogic Server authentication options back to user: weblogic, password: weblogic.
In the ALDSP Console (http://localhost:7001/ldconsole/), using the + icon, expand the ldplatform directory.
Note:
If you click the ldplatform name, the Application List page opens. You do not need this page for this lesson.
Click Evaluation. The Administration Control's General page opens.
Clear Check Access Control.
Click Apply.
Lesson Summary
In this lesson, you learned how to:
Activate application level security.
Set security permissions on both read and write function access.
Set security permissions on simple and complex elements.