Moving to Production Mode
Tutorial 19: Copying and Reinitializing Security Configurations
This tutorial describes how to copy a security configuration from deployment descriptors into the configured Authorization and Role Mapping providers' databases, so that you can use the Administration Console for subsequent modifications to security policies and security roles. It also describes how to reinitialize a security configuration using the original deployment descriptors.
The tutorial includes the following sections:
|
Prerequisites
Before starting this tutorial:
|
Procedure
This tutorial consists of three main steps:
Step 1: Copy a security configuration.
To copy security configurations for the adminWebApp Web application from its deployment descriptors into the configured Authorization and Role Mapping providers' databases, follow these steps:
Step 1: Specify security realm settings and deploy the Web application.
This setting causes the WebLogic Security Service to perform security checks on all URL (Web) and EJB resources. For more information, see Understanding How to Check Security Roles and Security Policies in Securing WebLogic Resources.
If All Web Applications and EJBs was already selected as the value of the Check Roles and Policies drop-down menu, just continue to step 4.
This setting causes WebLogic Server to copy security configurations for URL (Web) and EJB resources from deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. For more information, see Understanding What to Do on Future Redeploys of the WebLogic Resource in Securing WebLogic Resources.
Step 2: Verify the copied security policies (optional).
Listing 1: The adminWebApp Web Application web.xml Deployment Descriptor
<!DOCTYPE web-app (View Source for full doctype...)>
<web-app>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>images</web-resource-name>
<url-pattern>*.gif</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>UnsecureLoginAction
</web-resource-name>
<url-pattern>login.do</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>UnsecureLoginPages
</web-resource-name>
<url-pattern>Login.jsp</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>AdminActions</web-resource-name>
<description>These pages are only accessible by authorized administrators.</description>
<url-pattern>*.do</url-pattern>
<url-pattern>*.jsp</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>These are the roles who have access.</description>
<role-name>admin</role-name>
</auth-constraint>
...
</security-constraint>
...
<security-role>
<description>An administrator</description>
<role-name>admin</role-name>
</security-role>
</web-app>
The Caller is Granted the Role Policy Condition is highlighted and the Policy Statement list box reads:
Caller is Granted the Role
If you click a hyperlinked URL pattern that did not have a corresponding <http-method> element in the web.xml deployment descriptor, the Policy Statement list box displays the appropriate security policy when the Methods drop-down menu contains the value ALL. For example, the security policy for the URL pattern *.gif from Listing 1 can be viewed when the Methods drop-down reads ALL.
If the URL pattern does not have a corresponding <auth-constraint> element in the web.xml deployment descriptor, the security policy for that URL pattern will be created using the Anonymous global role (for example, the security policy for the URL pattern *.gif from Listing 1). For more information about default global roles, see Default Global Roles in Securing WebLogic Resources.
Step 3: Verify the copied security roles (optional).
Listing 2: The adminWebApp Web Application weblogic.xml Deployment Descriptor
<!DOCTYPE weblogic-web-app (View Source for full doctype...)>
<weblogic-web-app>
<context-root>admin</context-root>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>admin</principal-name>
</security-role-assignment>
</weblogic-web-app>
The Scoped Roles page displays all the scoped roles for this Web Application that are currently defined in the WebLogic Role Mapping provider's database, including the scoped role called admin.
Security roles obtained from deployment descriptors are always copied into the configured Role Mapping provider's database as scoped roles, with a URL pattern of /*.
Step 4: Revert the On Future Redeploys 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. If you do not perform this step or perform this step incorrectly, you see the following message the next time you load the Policy Editor page:
The information presented below may not be accurate. To ensure that you are viewing accurate information, you may need to delete and redeploy your WebLogic resources.
Step 2: Modify a security policy using the Administration Console.
Step 3: Reinitialize a security configuration.
To reinitialize security configurations for the adminWebApp Web Application from its deployment descriptors, follow these steps:
Step 1: Modify the On Future Redeploys setting.
This setting means that WebLogic Server will copy security configurations for URL (Web) and EJB resources from deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. For more information, see Understanding What to Do on Future Redeploys of the WebLogic Resource in Securing WebLogic Resources.
If All Web Applications and EJBs was already selected as the value of the Check Roles and Policies drop-down menu, just continue to step 4.
Step 2: Redeploy the adminWebApp Web application.
Note: For instructions about how to deploy Web Application and EJB modules, see Deploying WebLogic Server Applications.
Step 3: Verify that the security configuration has been reinitialized (optional).
The Caller is Granted the Role Policy Condition is highlighted and the Policy Statement list box reads:
Caller is Granted the Role
The policy statement you created using the Hours of Access are Between policy condition in Step 2: Modify a security policy using the Administration Console. is gone, because it was not defined in the deployment descriptor from which you just initialized the security configuration.
Step 4: Revert the On Future Redeploys 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. If you do not perform this step or perform this step incorrectly, you see the following message the next time you load the Policy Editor page:
The information presented below may not be accurate. To ensure that you are viewing accurate information, you may need to delete and redeploy your WebLogic resources.
Note: This setting means that you will set security for URL (Web) and EJB resources using the Administration Console, not deployment descriptors. For more information, see Understanding What to Do on Future Deploys of the WebLogic Resource in Securing WebLogic Resources.
|
Best Practices
|
The Big Picture
This tutorial shows you how to copy the security configuration for a Web Application from its deployment descriptors into the configured Authorization and Role Mapping providers' databases, so that you can use the Administration Console for subsequent modifications to the Web Application's security roles and security policies. The same example shows you how to reinitialize the security configuration using the Web Application's original deployment descriptors.
The full MedRec application uses the principles described in Tutorial 17: Securing Application and URL (Web) Resources Using the Administration Console and Tutorial 18: Securing Enterprise JavaBean (EJB) Resources Using the Administration Console (as well as programmatic security) to secure EJB resources for both MedRec administrators and patients.
|
Related Reading