Securing WebLogic Resources

 Previous Next Contents Index View as PDF  

Examples: Copying and Reinitializing Security Configurations for the basicauth Web Application

In this example, you will copy security configurations for the basicauth Web application into the configured Authorization and Role Mapping providers' databases so that you can use the Administration Console for subsequent modifications to security roles and security policies. After you make a modification to a security policy using the Administration Console, you will reinitialize the security configuration for the basicauth Web application using the original deployment descriptor. Therefore, this example consists of three main steps:

Note: Prior to reviewing this example, you should read: Techniques for Securing URL and EJB Resources; Prerequisites for Securing URL and EJB Resources; and Using the Combined Technique to Secure Your URL and EJB Resources.

 


Step 1: Copy Security Configurations for the basicauth Web Application

To copy security configurations for the basicauth Web application, follow these steps:

Step 1: Obtain the basicauth Web Application

Note: All instructions provided in this section assume that you are working in a Windows environment.

  1. Obtain the "Basic Authentication Sample Web Application" (available under Code Samples: WebLogic Server on the dev2dev Web site).

  2. Unzip the basicauth.zip file to a temporary directory (for example, C:\basicauth).

Step 2: Modify the Prerequisite Settings and Deploy the Web Application

Note: All instructions provided in this section assume that you are working in a Windows environment.

  1. Set the fullyDelegateAuthorization flag equal to true, using the instructions in How to Change the fullyDelegateAuthorization Flag.

    Notes: Recall what this setting means: you are telling WebLogic Server that you want the WebLogic Security Service to perform security checks on all URL (Web) and EJB resources. For more information, see Understanding the fullyDelegateAuthorization Flag.

    If the fullyDelegateAuthorization flag was already set to true, just continue to step 2.

  2. From the Windows Start menu, select Programs —> BEA WebLogic Platform 7.0 —> WebLogic Server 7.0 —> Server Tour and Examples —> Launch Examples Server to start the server called examplesServer.

    The fullyDelegateAuthorization flag appears in the console as the examplesServer starts, and the BEA WebLogic Server Out-of-the-Box Examples Index Page opens in your browser.

  3. Using the navigation tree at the left side of the Administration Console, expand Security, then Realms.

  4. Expand the myrealm security realm.

  5. On the General tab, uncheck the Ignore Security Data in Deployment Descriptors check box. (The check box may already be unchecked, as this is the default setting.)

    Note: Recall what this setting means: you are telling WebLogic Server to copy security for URL (Web) and EJB resources from the deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. For more information, see Understanding the Ignore Security Data in Deployment Descriptors Check Box.

  6. Click Apply to save your changes.

  7. If you had to set the fullyDelegateAuthorization flag to true in step 1 (that is, it was not already set this way), restart the server. (For help, see Starting and Stopping WebLogic Servers in the WebLogic Server Administration Guide.)

    If you did not have to modify the value of the fullyDelegateAuthorization flag in step 1, continue to step 8 without restarting the server.

  8. Using the Administration Console, deploy the basicauth Web application and target it to the examplesServer.

    Note: For instructions about how to deploy Web applications, see "Deploying J2EE Applications with the Administration Console" in Developing WebLogic Server Applications.

Step 3: Verify the Copied Security Policies (Optional)

  1. Open the web.xml deployment descriptor for the basicauth Web application, and record the content of any <url-pattern> and <http-method> elements, as well as any <role-name> subelements of the <auth-constraint> element. Listing 8-1 shows the relevant portions of the web.xml deployment descriptor file in bold font.

Listing 8-1 The basicauth Web Application web.xml Deployment Descriptor

<!DOCTYPE web-app (View Source for full doctype...)> 
<web-app>
   <welcome-file-list>
      <welcome-file>welcome.jsp</welcome-file>
   </welcome-file-list>
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Success</web-resource-name>
         <url-pattern>/welcome.jsp</url-pattern>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
         <role-name>developers</role-name>
      </auth-constraint>
   </security-constraint>
   <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>default</realm-name>
   </login-config>
   <security-role>
      <role-name>developers</role-name>
   </security-role>
</web-app>

  1. Using the navigation tree at the left side of the Administration Console, expand Web applications, then right-click basicauth.

  2. From the menu, select the Define Policy... option.

  3. On the General tab, in the URL Pattern text field, type: /welcome.jsp

  4. Click the Define Policy... button to proceed.

  5. On the Policy Editor page, use the Methods drop-down menu to select the method: POST.

    The Caller is Granted the Role Policy Condition is highlighted and the Policy Statement list box reads:

    Caller is Granted the Role

    developers

  6. Using the Methods drop-down menu, select the method: GET.

    The Caller is Granted the Role Policy Condition is highlighted and the Policy Statement list box reads:

    Caller is Granted the Role

    developers

Step 4: Verify the Copied Security Roles (Optional)

  1. Open the weblogic.xml deployment descriptor for the basicauth Web application, and record the content of any <security-role-assignment> elements, specifically focusing on the <role-name> and <principal-name> subelements. Listing 8-2 shows the relevant portions of the weblogic.xml deployment descriptor file in bold font.

Listing 8-2 The basicauth Web Application weblogic.xml Deployment Descriptor

<!DOCTYPE weblogic-web-app (View Source for full doctype...)> 
   <weblogic-web-app>
      <security-role-assignment>
         <role-name>developers</role-name>
         <principal-name>myGroup</principal-name>
      </security-role-assignment>
   </weblogic-web-app>

  1. Using the navigation tree at the left side of the Administration Console, right-click basicauth Web application.

  2. From the menu, select the Define Role... option.

  3. On the General tab, in the URL Pattern text field, type: /*

  4. Click the Define Role... button to proceed.

    The Select Roles page displays the scoped role called developers.

  5. Click the hyperlinked name: developers

  6. Click the Conditions tab.

    The Role Statement list box contains a Role Statement based on the content of the deployment descriptor's corresponding <principal-name> element, which in this case is the group called myGroup.

Step 5: Revert the Ignore Security Data in Deployment Descriptors Setting

Caution: You must perform this step. Failure to revert this setting may result in inconsistent security configurations when your URL (Web) resources are redeployed.

  1. Using the navigation tree at the left side of the Administration Console, expand Security, then Realms.

  2. Click the name of your security realm (for example, myrealm).

  3. On the General tab, click the Ignore Security Data in Deployment Descriptors check box. (That is, you should be putting a check mark in the box.)

    Note: Recall what this setting means: you are telling WebLogic Server that you will set security for Web application and EJB resources using the Administration Console, not deployment descriptors. For more information, see Understanding the Ignore Security Data in Deployment Descriptors Check Box.

  4. Click Apply to save your changes.

 


Step 2: Modify a Security Policy Using the Administration Console

  1. Using the navigation tree at the left side of the Administration Console, right-click basicauth.

  2. From the menu, select the Define Policy... option.

  3. On the General tab, in the URL Pattern text field, type: /welcome.jsp

  4. Click the Define Policy... button to proceed.

  5. On the Policy Editor page, use the Methods drop-down menu to select the method: POST.

  6. In the Policy Condition list box, highlight the Hours of Access are Between policy condition.

  7. Click Add.

  8. Click OK in the Time Constraint window to select the default start and end times.

    The Policy Statement list box reads as follows:

    Caller is Granted the Role

    developers

    and Hours of Access are Between

    08:00:00 and 19:00:00

  9. Click Apply to save your changes.

  10. Using the Methods drop-down menu, select the method: POST, and verify that there are two expressions in the Policy Statement list box.

 


Step 3: Reinitialize Security Configurations for the basicauth Web Application

To reinitialize security configurations for the basicauth Web application from its deployment descriptor, follow these steps:

Step 1: Modify the Ignore Security Data in Deployment Descriptors Setting

  1. Using the navigation tree at the left side of the Administration Console, expand Security, then Realms.

  2. Expand the myrealm security realm.

  3. On the General tab, uncheck the Ignore Security Data in Deployment Descriptors check box.

    Note: Recall what this setting means: you are telling WebLogic Server to copy security for URL (Web) and EJB resources from the deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. For more information, see Understanding the Ignore Security Data in Deployment Descriptors Check Box.

  4. Click Apply to save your changes.

Step 2: Redeploy the basicauth Web Application

  1. Using the navigation tree at the left side of the Administration Console, expand Deployments, then click Web Applications.

  2. Click the basicauth Web application.

  3. Click the trash can icon that is located in the same row as the basicauth Web application.

  4. Click Yes, then the Continue link to delete the basicauth Web application.

    The deleted Web application or EJB no longer appears in the table.

  5. Redeploy the basicauth Web application, targeting it to the examplesServer.

    Note: For instructions about how to deploy Web applications and EJBs, see "Deployment Tools and Procedures" in Developing WebLogic Server Applications.

Step 3: Verify That the Security Configuration Has Been Reinitialized (Optional)

  1. Using the navigation tree at the left side of the Administration Console, right-click basicauth..

  2. From the menu, select the Define Policy... option.

  3. On the General tab, in the URL Pattern text field, type: /welcome.jsp

  4. Click the Define Policy... button to proceed.

  5. On the Policy Editor page, use the Methods drop-down menu to select the method: POST.

    The Policy Statement list box reads as follows:

    Caller is Granted the Role

    developers

Step 4: Revert the Ignore Security Data in Deployment Descriptors Setting

Caution: You must perform this step. Failure to revert this setting may result in inconsistent security configurations when your URL (Web) resources are redeployed.

  1. Using the navigation tree at the left side of the Administration Console, expand Security, then Realms.

  2. Click the name of your security realm (for example, myrealm).

  3. On the General tab, click the Ignore Security Data in Deployment Descriptors check box. (That is, you should be putting a check mark in the box.)

    Note: Recall what this setting means: you are telling WebLogic Server that you will set security for Web application and EJB resources using the Administration Console, not deployment descriptors. For more information, see Understanding the Ignore Security Data in Deployment Descriptors Check Box.

  4. Click Apply to save your changes.

 

Back to Top Previous Next