ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Java and Security, Part 1
Pages: 1, 2, 3, 4

Policies

Security policies let you protect a wide variety of server resources. For instance, you can decide who has access to the Administration Console, who can start and stop the servers, and who can access the connection pools, web applications, EJBs, enterprise applications, J2EE connectors, a particular branch of the JNDI tree, and more. Security policies offer very tight control over the authorization settings within the WebLogic domain. Although scoped roles look very similar to policies, policies define access control while roles do not. In summary:



  • A policy statement is used to protect a resource.
  • A policy statement lets you specify a number of conditions under which users may access the resource.

A security policy uses a superset of the conditions that are available to a role. You can define a policy in terms of a logical combination of usernames, group names, time-of-day settings, and roles. The roles used in a policy can be either global roles, or those scoped to the resource for which you are defining the policy.

Note: A WebLogic resource is protected only when it has been assigned a security policy. Some WebLogic resources come with a set of default policies applied to them.

Whereas role information is stored by the Role Mapping Provider, policy information is stored by the Authorization Provider. Even though you may configure the security policies in the same way as the roles, we recommend that you set up roles to identify user responsibilities and create policies to specify access restrictions using these roles. That is, you should define roles in terms of existing users, groups, and time-of-day settings, and then you can use these roles to configure a policy statement for the resource. This scheme fits nicely with the J2EE role-based security model covered earlier in the section "Overview."

A policy can be assigned in a number of ways:

  • WebLogic can assign policies to web applications and EJBs automatically, after it has read their deployment descriptors.
  • The Administrator can assign policies to WebLogic resources manually and tweak their configuration.
  • WebLogic provides default security policies that are applied to many resources.

Using the Administration Console

An Administrator can explicitly define security policies that help protect WebLogic resources. You can assign a security policy in the same way that you define a scoped role for a resource. Simply select the resource from the left pane of the Administration Console, then right-click and choose the Define Security Policy option instead. EJBs offer an additional option, "Define Security Policies and Roles for Individual beans," that allows you to define a policy for a particular EJB and to further limit this policy to selected EJB methods. Web service modules offer similar functionality, allowing you to define a policy for a particular web service within a module and to further limit the policy to selected web service operations. This same functionality exists for JMS destinations, whereby the policy can be limited to either a send, receive, or browse operation on a queue, or to a send or receive operation on a topic.

Enabling user-defined policies

In WebLogic 8.1, new policies that you create using the Administration Console will, by default, not be applied. Instead, only those policies that were defined using deployment descriptors will be in operation. For example, if you add a new scoped policy for all .html files in a web application, and assuming that you had no such security constraint defined in the deployment descriptors, your new scoped policy will not be operational. To toggle this behavior, you need to select the security realm from the left pane of the Administration Console and then select the General tab. The Check Roles and Policies setting can assume two possible values.

Web Applications and EJBs Protected by DD
This option ensures that WebLogic honors only those security constraints defined in the deployment descriptors of web applications and EJB modules. This is the default behavior of the security realm. All Web Applications and EJBs This option ensures that WebLogic honors any security policies that are configured for the web applications and EJB modules using the Administration Console.

All Web Applications and EJBs
This option ensures that WebLogic honors any security policies that are configured for the web applications and EJB modules using the Administration Console.

Thus, you must change the value of the Check Roles and Policies setting to the latter option if you need to enable the policies defined using the Administration Console.

Using the deployment descriptors

WebLogic supports the J2EE security model, which relies on the security roles defined in the descriptor files to determine access privileges. WebLogic's Authorization Provider examines the deployment descriptors when the EAR or WAR is deployed and creates internal security roles based on the configuration settings. In addition, the provider defines a security policy that grants access to all principals that belong to these roles. Later, we'll see how to alter the default behavior of the providers by instructing them to ignore the security data held in the deployment descriptors.

Default policies

WebLogic comes equipped with a number of default security policies—for example, WebLogic supports a default policy that restricts access to the Administration Console. The following security policies are based on role membership:

Administrative resources
The Administration Console and other administrative resources are protected by a security policy that demands that the caller be in one of the following roles: Admin, Deployer, Operator, or Monitor.

Server resources
Resources under the Server node in the Administration Console are protected by a security policy that demands that the caller be either in the Admin or Operator roles.

COM resources
Resources under the Services/jCOMnode in the left pane of the Administration Console are protected by a policy that demands that the caller be in the JCOM role.

By default, all application-specific resources, such as those related to JDBC, JMS, EJB, EIS, MBean, and Web Services, are accessible to all users. This is possible because these resources are protected by the default policy, which demands that the caller be in the everyone group. You can always view the default security policy that applies to a WebLogic resource. For instance, if you right-click the Connection Pool node under the Services/JDBC node and then choose the Define Security Policy option, you can view the default policy for all connection pools.

When you configure a new resource—for example, a new JDBC pool or a web services component - it automatically inherits the default security policy. Any new security policy associated with a resource also uses the inherited policy conditions. However, if you define a new security policy for a resource with new policy conditions, these settings override the inherited policy conditions. That is, if you define a policy for a resource, the inherited policy conditions are ignored. For instance, if you define a policy constraint for a JDBC pool that requires that the caller be in the role MyRole, it overrides the default policy constraint that the caller be a member of the group everyone.

Ignoring the Deployment Descriptors

When an application is deployed, WebLogic inspects the security constraints defined in the deployment descriptors and sets up the appropriate role and policy statements in the various providers. Because these roles and policy statements are not persisted to the deployment descriptors (but rather to an internal store), reading this information from the descriptor files the next time the application is deployed means that WebLogic may overwrite any changes that you make to the role and policy information. You can prevent this overwriting behavior by instructing WebLogic to ignore the security constraints in the deployment descriptors the next time the application is deployed. To configure this, navigate to the security realm using the left pane of the Administration Console, and then in the General tab change the value of the On Future Re-Deploys* attribute. The default value for this setting—i.e., initialize roles and "policies" from DD—ensures that WebLogic does create the roles and policies based on the security information held in the deployment descriptors. If you set the attribute to "ignore roles and policies from DD," you can prevent WebLogic from reading the security information held within the deployment descriptors.

Because the providers manage all the information about the roles and policy statements, you have greater control over this access control information now that you can decide when WebLogic should ignore the security data in the deployment descriptors. You have two basic options, each with their own security implications:

  • If you choose to ignore the deployment descriptors before actually deploying an application, the security constraints for the application need to be configured manually from the Administration Console. The providers will persist the access control information in their own stores, and the security data in the deployment descriptors will be ignored completely.

  • If you choose to ignore the deployment descriptors after deploying the application, the providers already will be populated with the security constraints in the descriptor files, which you can later further refine from the Administration Console. Once again, the providers will store this information in their own stores. However, because the security settings in the descriptor files have been ignored, they can no longer override any changes you’ve made to the roles and policy statements.

Summary

Figure 17-1 summarizes the security architecture that we have just described.

Static structure of authentication components
Figure 17-1. Static structure of authentication components

As you can see from the figure, users may belong to groups, and groups may contain other groups. Roles may be defined in terms of users and/or groups. Roles can either be global or scoped to a particular kind of resource. Here we haven’t shown all resources—just the hierarchical connection pool resources. A particular connection pool is contained in the Connection Pools resource.

Note: Strictly speaking, policies are applied to a ResourceMBean. At runtime, a ResourceMBean will exist that represents each actual JDBC Connection Pool, all of which extend to another MBean that represents the "container" holding all of the connection pools. Inheritance of policies works because the ResourceMBean extend each other in this way.

Scoped roles and policies may be associated either with the Connection Pools container (in which case it is inherited by all its instances), or with a particular JDBC Pool itself. All policies are scoped because they are always associated with a particular resource.

Next week's excerpts from Chapter 17 of WebLogic: The Definitive Guide will cover WebLogic's various security providers and their default implementations, along with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion Providers.

Avinash Chugh, Jon Mountjoy presently works as Senior Development Manager for a firm that produces software for the regulated industries (finance, energy, pharmaceutics).


Return to ONJava.com.