This document is written primarily for Server Administrators. Server Administrators work closely with Application Architects to design a security scheme for the server and the applications running on the server, to identify potential security risks, and to propose security configurations that prevent security problems. Related responsibilities may include maintaining critical production systems, configuring and managing security realms, implementing authentication and authorization schemes for server and application resources, upgrading security features, and maintaining security provider databases. Server Administrators have in-depth knowledge of the Java security architecture, including Web application and EJB security, Public Key security, and SSL.
This document is targeted toward Server Administrators who use the WebLogic Server Administration Console, and should be used in conjunction with Managing WebLogic Security to ensure that security is completely configured for a WebLogic Server deployment.
Terms and Concepts
WebLogic Server security includes many unique terms and concepts that you need to understand. These terms and concepts—which you will encounter throughout the WebLogic Server security documentation—are defined in the Terminology section and the Security Fundamentals section of Introduction to WebLogic Security, respectively.
Overview of Securing WebLogic Resources
Figure 1-1 illustrates the overall process for securing WebLogic resources, and a brief explanation follows.
Figure 1-1 Securing WebLogic Resources
Administrators statically assign users to groups, which can represent organizational boundaries. The same user can be a member of multiple groups. Figure 1-1 shows three groups with two users each. User 1 and User 3 are members of multiple groups.
Note: BEA recommends assigning users to groups because doing so is more efficient for administrators who work with large numbers of users.
Administrators create a role statement based on their organization's established business procedures. The role statement includes a role condition that specifies when a particular group should be granted the security role.
At runtime, the WebLogic Security Service compares the groups against the role condition to determine whether they should be dynamically granted a security role. This process is referred to as role mapping. In Figure 1-1, Group 2 is the only group that is granted a security role.
Note: Individual users could also be granted a security role, but this is a less typical practice.
Administrators create a policy statement based on their organization's established business procedures. The policy statement includes a policy condition that specifies when a particular security role should be granted access to a protected WebLogic resource.
At runtime, the WebLogic Security Service uses the security policy and the WebLogic resource itself to determine whether access to the protected WebLogic resource should be granted. Only users who are members of the group that is granted the security role can access the WebLogic resource. In Figure 1-1, User 3 and User 6 can access the protected WebLogic resource because they are members of Group 2.
Securing WebLogic Resources: Main Steps
The main steps for securing a WebLogic resource are as follows:
If you want to copy security configurations from existing deployment descriptors upon the initial deployment of URL or EJB resources, or reinitialize the security configuration for URL or EJB resources to their original state (as specified in the deployment descriptors), follow the instructions in Using the Combined Technique to Secure Your URL and EJB Resources.
Use the Administration Console to secure your WebLogic resource. Follow these steps:
Create users and groups—representations of individuals and collections of individuals—who may be granted a security role. See Creating Users and Creating Groups for step-by-step instructions.
Create security roles—dynamically computed privileges granted to users or groups based on specific conditions—which are used to restrict access to WebLogic resources. See Security Roles for step-by-step instructions.
Note: BEA recommends creating security roles and using them (rather than users or groups) to secure WebLogic resources, because doing so makes it more efficient for administrators who work with large numbers of users.
Create a security policy—an association between the WebLogic resource and a user, group, or security role—that specifies who has access to the WebLogic resource. See Security Policies for step-by-step instructions.
