![]() ![]() ![]() ![]() ![]() ![]() ![]() |
This chapter introduces terms and concepts, provides a workflow summary, and outlines the main steps for securing WebLogic resources:
To secure a resource in a WebLogic Server domain, you create a policy and an optional role. A resource is an entity (such as a Web Service or a server instance) or an action (such as a method in a Web Service or the act of shutting down a server instance). A policy specifies which users, groups, or roles can access the resource under a set of conditions. A security role, like a security group, grants an identity to a user. Unlike a group, however, membership in a role can be based on a set of conditions that are evaluated at runtime.
Figure 2-1 describes how you create roles and policies and how the Security Service uses them to determine whether a client can access a resource. A brief explanation follows the figure.
BEA recommends assigning users to groups because doing so increases efficiency for administrators who work with many users.
Individual users can also be granted a security role, but this is a less typical practice.
WebLogic Server provides two techniques for using a single policy to protect a collection of resources:
You can create a policy that protects all resources of a specific type. Such policies are called root-level policies. For example, you can create a root-level policy for the Web Service type. All Web Services that you deploy in the domain for which you have defined this root-level policy will be protected by the root-level policy.
If you define a policy for a specific Web Service, then the Web Service will be protected by its own policy and will ignore the root-level policy.
All of the resources within a J2EE application or module that you deploy exist within a hierarchy, and policies on resources higher in the hierarchy act as default policies for resources lower in the same hierarchy. Policies lower in a hierarchy always override policies higher in the hierarchy.
For example, EnterpriseApp1contains EJB ModuleA along with a Web application and a JDBC module (see Figure 2-2). You create a policy for EnterpriseApp1 and for method Y within EJB ModuleA. When an EJB client attempts to invoke method Y, the WebLogic Security Service enforces the specific policy and ignores the policy for the enterprise application.
When a client requests access to EJB method X (which is not protected by its own policy), the WebLogic Security Service asks:
You can see a visual representation of resource and policy hierarchies in the Administration Console on the security realm's Roles and Policies: Policies page. For information about accessing this page, see Create Policies for Resource Instances in the Administration Console Help.
To design a set of roles and policies that can secure the resources in your domain:
To see a list of all the types of resources that could be in any given domain, see Resource Types You Can Secure with Policies.
For planning purposes, organize the resources into the following categories:
config.xml
).For these tasks, WebLogic Server already provides a detailed, layered security scheme that grants different types of access to four security roles (Admin, Deployer, Operator, Monitor). For most environments, this security scheme is adequate and only requires you to assign users to the four default security roles appropriately (see step 3).
While it is possible to modify some parts of this layered security scheme, such modifications are usually not needed and require careful planning to maintain consistency between the different layers. See Administrative Resources, Server Resources and JMX Resources.
The J2EE platform already provides a standard model for securing Web applications and EJBs. In this standard model, developers define role mappings and policies in the Web application or EJB deployment descriptors.
You can use the standard model or you can use the Administration Console to define polices and roles, which offers unified and dynamic security management. See Options for Securing Web Application and EJB Resources.
By default, these resources are not protected by policies; you must define policies to determine who can access them.
A root-level policy applies to all instances of a resource type. For example, if you define a root-level policy for the Web Services resource type, then the policy will apply to all Web Services in your domain.
A scoped policy applies to a specific resource instance and overrides a root-level policy.
See Security Policies.
You can create global roles, which can be used in any policy, or scoped roles, which can be used only in a policy for a specific resource instance.
Because both roles and policies can evaluate a set of conditions at runtime, you should consider which parts of your security data should be static and which should be dynamic. For example, you might want some policies to always allow one specific role to access a resource, and then you use conditions in the role's definition to move users in and out of the roles as needed. In other cases, you might want a static role definition and create a policy that allows access to different roles at different times of the day.
As a general guideline, if you base the authorization decision on the resource instead of the entities (roles) who can access the resource, you would add conditions to the security policy. If you base authorization on who can access the resource, then you would add conditions to the security role.
For an example of authorization based on who can access the resource, consider a manager who is going on vacation. You can temporarily place a user in a Manager
security role. Dynamically granting this security role means that you do not need to change or redeploy your application to allow for such a temporary arrangement. You simply specify the hours between which the temporary manager should have special privileges. Further, you do not need to remember to revoke these special privileges when the actual manager returns as you would if you temporarily added the user to a management group.
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 modify your realm to use these WebLogic providers, you can configure the maximum number of items that they store in the caches.
Note: | By default, security realms in newly created domains include the XACML Authorization and Role Mapping providers. The XACML providers use their own cache, but this cache is not configurable. WebLogic Server also includes the WebLogic Authorization provider (DefaultAuthorizer ) and the Role Mapping provider (DefaultRoleMapper ), which use a proprietary policy language. The DefaultAuthorizer and DefaultRoleMapper providers are the only BEA provider with configurable caches of entitlement data. |
By default, the Weblogic Authorization and Role Mapping providers store the following number of items in each cache:
This cache contains the name of each role that has been looked up and the policy that protects it.
This cache contains each predicate that the WebLogic entitlements engine has looked up.
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:
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
![]() ![]() ![]() |