Securing WebLogic Resources

Introduction to Securing WebLogic Resources

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

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

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.

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

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.

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.

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.

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:

Determine which WebLogic resource to secure. See Types of WebLogic Resources.

If you want to secure a URL (Web) or EJB (Enterprise JavaBean) resource:

Decide which technique you will use. See Techniques for Securing URL and EJB Resources.

Review important information about securing URL and EJB resources to prevent overriding security configurations. See Prerequisites for Securing URL and EJB Resources.

If you want to use the WebLogic Server Administration Console to secure your URL or EJB resource, follow the instructions in step 3.

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.

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:

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

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.

Best Practices: Configure Entitlements Caching When Using WebLogic Providers

The WebLogic Authorization provider (DefaultAuthorizer) and the WebLogic Role Mapping provider (DefaultRoleMapper) improve performance by caching the roles, predicates, and resource data that they look up. If you use these WebLogic providers, you can configure the maximum number of items that they store in the caches.

By default, the Weblogic Authorization and Role Mapping providers store the following number of items in each cache:

2000 items in the roles cache

This cache contains the name of each role that has been looked up and the policy that protects it.

200 items in the predicates cache

This cache contains each predicate that the WebLogic entitlements engine has looked up.

5000 items in the resources cache

This cache contains the name of each resource that has been looked up and the policy that protects it.

If a cache exceeds its maximum size, the WebLogic entitlements engine removes the least recently used (LRU) item from the cache.

If the applications on a WebLogic Server instance use more than 2000 roles or 5000 resources, consider increasing the cache sizes. (The WebLogic providers include less than 50 predicates, so there is no need to increase the size of this cache.)

To change the maximum number of items that a cache contains, pass one of the following system properties in the java startup command for a WebLogic Server instance:

-Dweblogic.entitlement.engine.cache.max_role_count=max-roles

where max-roles is the maximum number of roles that you want to cache.

-Dweblogic.entitlement.engine.cache.max_predicate_count=max-predicates

where max-predicates is the maximum number of predicates that you want to cache.

-Dweblogic.entitlement.engine.cache.max_resource_count=max-resources

where max_resource_count is the maximum number of resources that you want to cache.

By default, the WebLogic providers add items to the cache as they use them. With this configuration, the initial lookup of entitlement data takes longer than subsequent lookups. You can, however, decrease the amount of time needed for an initial lookup by configuring a WebLogic Server instance to load the caches during its startup cycle. To do so, pass the following system property to the server's java startup command:

-Dweblogic.entitlement.engine.cache.preload=true

For example:

java -Dweblogic.entitlement.engine.cache.max_role_count=6001 -Dweblogic.entitlement.engine.cache.max_resource_count=3001 -Dweblogic.entitlement.engine.cache.preload=true weblogic.Server