Introduction to Securing WebLogic Resources

The following sections describe key concepts and tasks for securing WebLogic resources:

• Overview of Securing WebLogic Resources
• Audience for This Guide
• Terms and Concepts
• Securing WebLogic Resources: Main Steps

 

---

Overview of Securing WebLogic Resources

A WebLogic resource represents an underlying WebLogic Server entity that can be protected from unauthorized access using security roles and security policies. Examples of WebLogic resources include Enterprise Applications (EARs), EJBs (JARs), and Web Applications (WARs). For more information about the different types of WebLogic resources, see Types of WebLogic Resources.

Figure 1-1 illustrates the overall process for securing WebLogic resources, and a brief explanation follows.

Figure 1-1 Securing WebLogic Resources

1. 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.

   BEA recommends assigning users to groups because doing so increases efficiency for administrators who work with many users.

2. Administrators create a security role based on their organization's established business procedures. The security role consists of one or more role statements, each of which include a role condition. The role condition specifies the circumstances under which a particular group should be granted the security role.
3. At runtime, the WebLogic Security Service compares the groups against the role condition(s) to determine whether users in the group 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.

   Individual users can also be granted a security role, but this is a less typical practice.

4. Administrators create a security policy based on their organization's established business procedures. The security policy consists of one or more policy statements, each of which include a policy condition. The policy condition specifies the circumstances under which a particular security role should be granted access to a protected WebLogic resource.
5. 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, and Group 2 is granted the necessary security role.

 

---

Audience for This Guide

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 can 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 Enterprise Application, Web Application and EJB security, Public Key security, and SSL.

This document written for 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.

 

---

Securing WebLogic Resources: Main Steps

The main steps for securing a WebLogic resource are:

1. Determine which WebLogic resource to secure. See Types of WebLogic Resources.
2. If you want to secure a URL (Web) or EJB (Enterprise JavaBean) resource:
   1. Decide which technique you will use. See Techniques for Securing URL and EJB Resources.
   2. Review important information about securing URL and EJB resources to prevent overriding security configurations. See Prerequisites for Securing URL and EJB Resources.
   3. If you want to use the WebLogic Server Administration Console to secure your URL or EJB resource, follow the instructions in step 3.
   4. If you want to use deployment descriptors to secure your URL or EJB resource, see Adding Declarative Security to Web Applications" or Adding Declarative Security to EJBs" in Programming WebLogic Security, respectively.
   5. 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.
3. Use the Administration Console to secure your WebLogic resource:
   1. 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.
   2. 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 Working with Scoped Roles for step-by-step instructions.

      BEA recommends creating security roles and using them (rather than users or groups) to secure WebLogic resources, because doing so increases efficiency for administrators who work with many users.

   3. 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 Working with Security Policies.