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

The Default Connection Filter

WebLogic comes preconfigured with a useful connection filter that can process a number of filter rules defined using the Administration Console in the Connection Filter Rules setting. The connection filter attempts to match an incoming connection against all the rules, beginning from the first rule in the list. If a matching rule is found, the connection is allowed (or disallowed) depending on the rule’s action. If no matching rule is found, the incoming connection is permitted.



You can specify any number of rules; each rule should be on a single line. The syntax for a connection filter rule is shown here:

target localAddress localPort action protocolList

Here are the definitions for the parameters of a connection filter rule:

  • The target parameter specifies the client hosts that the rule must examine. We discuss its syntax later.
  • The localAddress parameter refers to the server's host address to which the client connects. If you specify an asterisk (*), this matches all local IP addresses.
  • The localPort parameter indicates the server port to which the client connects. If you specify an asterisk (*), this matches all available ports.
  • The action parameter indicates whether the rule should allow or reject the incoming connection request. It can take two possible values: allow or deny.
  • Use the protocolList parameter to define a space-separated list of protocol names that should be matched. The protocol names can be: http, https, t3, t3s, giop, giops, dcom, or ftp. If no protocols are listed, the rule checks for all protocols. Versions of WebLogic 7.0 and WebLogic 8.1 also permit the ldap protocol to be specified.

You also can include a # character anywhere on the line. Any text after this character until the end of the line is treated as a comment.

A filter rule can define the target parameter in two forms:

  • It can be a "fast" rule if the value for the target parameter is either a hostname or an IP address.
  • It can be a "slow" rule if the value for the target parameter is a domain name.

For fast rules, you can specify either the client's hostname or IP address. The IP address can be followed by an optional netmask, the two being separated by a / character. If you supply a hostname that resolves to a list of IP addresses, the server automatically generates multiple versions of the same rule for each IP address when it boots up. These rules are called "fast" because the server eventually has a list of rules that use static IP addresses; therefore, no connect-time DNS lookups are required once the server is up and running. All hostnames are resolved to their IP addresses when the server boots and goes through all the filter rules. Here are a few examples of fast rules:

www.oreilly.com 127.0.0.1 7001 allow t3 # allow t3 requests from www.oreilly.com
10.0.20.30/255.255.0.0 127.0.0.1 7001 allow t3 t3s http https

Notice how the second filter rule uses a netmask.

For slow rules, the value for the target parameter is a domain name beginning with an asterisk (*). An asterisk may be used only at the head of the domain name. Here is an example of a slow rule:

*.oreilly.com 127.0.0.1 7001 allow t3

This rule allows incoming T3 connections on port 7001 from any client that runs on a host within the oreilly.com domain. It's called a "slow" rule because it requires a connect-time DNS lookup in order to execute the match, so it is literally slower than the fast rules.

The following rule is very handy for denying all access to your server:

0.0.0.0/0 deny # refuse the connection request

You can define this rule at the end of the list of filter rules, and thereby deny access to all connections that fail to match any of the previous rules in the list. In this way, you can ensure that an incoming connection request is allowed only if it matches one of the preceding filter rules.

The Security Provider Architecture

Let's now turn our attention to WebLogic's infrastructure for application-level security. WebLogic defines a standard set of SSPIs that provide high-level security services. WebLogic also supplies a default set of security providers that implement these SSPIs. These default security providers support and enhance the standard J2EE rolebased security framework. In fact, they also allow you to programmatically control its behavior. There are two important characteristics of this security framework:

Modular
The SSPIs are split into discrete modules so that each security provider can deal with different but specific aspects of WebLogic's security (e.g., authentication, authorization, auditing, and more).

Pluggable
Because these security providers live behind a layer of SSPIs, WebLogic makes it easier to replace or enhance the default implementation with your own or a third-party implementation.

The SSPIs hide the actual implementation of the security providers, thereby enabling you to plug in and play your own modules and modify selected aspects of the security. For instance, the default Authentication Provider can be replaced with one that supports some form of biometric recognition, or the Auditing Provider can be replaced with one that notifies interested parties after a user has made a certain number of failed attempts to log in.

A security realm is a logical grouping of users, groups, roles, and security policies, along with a complete set of security providers. By default, WebLogic Server comes equipped with two such realms: the legacy compatibility realm that provides support for WebLogic 6.x–type security configurations, and the new default realm. The default realm which is often referred to by its default name myrealm is WebLogic's standard implementation of the security providers. Although you can configure multiple realms for a domain, one realm can be active only; this active realm controls all aspects of the domain’s security.

You can determine which realm your domain is set up to use by selecting the domain from the left frame of the Administration Console and then choosing the View Domain-Wide Security Settings option. The Configuration/General tab displays a Default Realm field that indicates the security realm currently being used by your domain. The Administration Console lets you configure virtually all aspects of the security realm. You can view and modify the realm's configuration by selecting the realm from under the Security/Realms node in the left pane of the Administration Console. Here, you will find subnodes for all the security providers within the realm, together with access to the realm’s users, groups, and roles.

To understand how WebLogic's default security realm works, you need to understand the authentication and authorization structure that WebLogic imposes on its resources and how it integrates with the standard J2EE role-based security. The remainder of this section is dedicated to exploring these concepts. The following section examines the security providers in more detail.

Overview

WebLogic's authentication and authorization providers, part of the default implementation of the SSPIs, rely on the important concepts shown in the following list.

  • A user, which represents a person, system, or Java client
  • A group, which represents a static collection of users
  • A role, which represents a dynamic collection of users
  • A security policy, which defines which users are granted access to a WebLogic resource

You can use WebLogic to configure these entities and thereby protect any resource within a domain, right from the call to an EJB method all the way through to a particular operation from the Administration Console. This framework prohibits unauthorized access both from within (e.g., a servlet invoking an EJB method) and from without (e.g., a Java client attempting to use a JDBC data source).

To place these concepts in context, let's refer back to the "Security Configuration" section in Chapter 2, where we examined how to protect the web resources in the /admin directory of a web application. In the standard web.xml deployment descriptor, we defined a security constraint that granted access to a security role named webadmin:

<!-- web.xml entry: -->
<security-constraint>
 <web-resource-collection>
 <web-resource-name>Admin Resources</web-resource-name>
  <description>security constraints for admin stuff</description>
  <url-pattern>/admin/*</url-pattern>
  <http-method>POST</http-method>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <role-name>webadmin</role-name>
 </auth-constraint>
 <user-data-constraint>
  <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>
</security-constraint>

Of course, this setup relies on a security role that we also defined in the descriptor file:

<!-- web.xml entry: -->
<security-role>
 <role-name>webadmin</role-name>
</security-role>

Up until this point, we have utilized the standard J2EE security features found in the deployment descriptors. Now we have to assign the virtual security role defined in the web.xml file to an actual physical entity in WebLogic Server. This is achieved by associating the role name to a number of principals already configured in WebLogic Server. The weblogic.xml descriptor file for the web application holds this mapping:

<!-- weblogic.xml fragment -->
<security-role-assignment>
 <role-name>webadmin</role-name>
 <principal-name>jmountjoy</principal-name>
 <principal-name>achugh</principal-name>
</security-role-assignment>

This XML fragment correlates the webadmin role defined and used within the web application with the actual WebLogic users jmountjoy and achugh. In this way, we are able to prohibit users who are not in the webadmin role from accessing web content under the /admin folder. Let’s now look at just how this setup protects the web resources in the web application.

A protected resource restricts access to only a subset of users. Any user that satisfies the access constraints laid down on the protected resource is then authorized to access the resource. WebLogic lets you protect a variety of resources: web applications, URLs (as in the earlier example), individual EJB methods, web services, connection pools, and even branches of the JNDI tree. For instance, you could ensure that only certain users are allowed to access a connection pool or invoke a method on a protected EJB. In the case of our sample web application, the set of URLs matching the pattern /admin/* represents a protected resource. This means that you can easily set up a secure environment in which applications are forced to obey the security constraints that you’ve laid out. WebLogic also makes it easy to adapt the configuration according to your needs with minimal code changes. In the case of our sample web application, the security constraints are defined declaratively in the deployment descriptors. Thus, you can adjust the security settings with no code changes.

The access control mechanism relies on the notion of an authenticated user. The user represents an authenticated entity—it could be a person (as in this case) or an external, client program. A user may authenticate itself in different ways. Over the Web, a user may be required to fill in a login form. A Java client application, on the other hand, may rely on JAAS authentication to establish trust with WebLogic Server. In our example, the user is determined from the username and password (login credentials) supplied over the Web. In general, a user has a number of principals (identities) associated with it as a result of an authentication. For instance, the principals associated with the system user after successful authentication include the system user itself and the group to which it belongs—i.e., the Administrators group. Some users may not authenticate at all, in which case they will remain anonymous.

When the domain holds an overwhelming number of WebLogic users, it becomes cumbersome to manage the security needs of each individual user. For this reason, WebLogic lets you configure static collections of users, called groups. From a security point of view, if a role or policy statement is applied to a group, the role or policy is assigned to all members of the group. From an administration point of view, it is easier to manage a handful of groups rather than (say) several hundred users. Remember, a group is a static collection of users. An administrator explicitly defines the members of a group at configuration time. As we saw earlier, a group can also act as a security principal. So, for instance, our weblogic.xml descriptor file could easily map the security role to the name of an existing group:

<!-- weblogic.xml fragment -->
<security-role-assignment>
 <role-name>webadmin</role-name>
 <principal-name>someAdminGroup</principal-name>
</security-role-assignment>

In this case, access to the web content would be restricted only to all users within someAdminGroup.

A security role represents a dynamic collection of users whose membership is evaluated at runtime based on the subject’s principals and other membership criteria. Whether a user is in a role depends on whether the user satisfies the membership conditions of the role at runtime. You can specify a number of membership conditions for the role. These include a logical mix of usernames, group names, and times of access during the day. For instance, you may define the membership condition for the DayShopper role as being "any user who belongs to the Shopper group and the time of access is between 8:00 a.m. and 5:00 p.m.". You may assign a number of roles to a resource in order to help specify the authorization conditions of the resource. Note that the roles themselves do not guarantee access control, they just facilitate in the definition of a policy statement that ultimately protects access to the target resource. In terms of the earlier example, we created a role called webadmin. The membership conditions for the role are simple: the client has to be authenticated as either jmountjoy or achugh before the web application considers it in the webadmin role.

You can protect a WebLogic resource by defining a policy statement for it. A security policy is a statement about access—it determines which users will have access to the resource. Just as you can with roles, you can define a policy in terms of a logical combination of a number of conditions: usernames, group names, the time of access during the day, and role names. For instance, you could assign the following policy to a JDBC pool: "the caller must belong to the DayShopper role or the Administrator group." This means that only authenticated users who belong to the Administrator group or pass the membership criteria of the DayShopper role may access the pool. If any user fails these access control checks defined for the JDBC pool, WebLogic will raise an authorization exception.

Now let's revisit the earlier security constraints on our web application in terms of these concepts. The weblogic.xml descriptor file defines a webadmin role. At deploy time, WebLogic reads this descriptor file and creates a webadmin role within its internal security configuration. This internal security role is configured to ensure that only the users achugh and jmountjoy can qualify for membership to this role. Thus, the J2EE role gets mapped to a WebLogic role, whereas the role-to-principal(s) assignment defines the membership criteria for the internal role.

In addition, WebLogic creates and assigns a policy statement to the web application that protects all web resources that match the URL pattern /admin/*. The policy statement will grant access to any caller satisfying the following condition: "the caller is in the webadmin role." Through this policy statement, WebLogic can ensure that any user who isn’t a member of the webadmin role is unable to access the web content under the /admin folder. Thus, WebLogic relies on a behind-the-scenes policy statement to enforce the security constraints defined by the deployment descriptors. Later, we see how you can explicitly create your own policy statements.

Users and Groups

To list the users that belong to a realm, select the realm from the Administration Console and choose the Users node. You then can use the righthand frame to view all the users or filter the list. The System user account also will be part of the list— this is the Administration user account that was defined when you used the Configuration Wizard to create the domain. Select the "Configure a new User" option to create a new user. For each user, you need to specify a name, a short description, and a password. Note that all usernames within a realm must be unique. The default provider uses case-insensitive usernames. The user may belong to one or more groups.

To list and edit all the groups that belong to a security realm, select the realm from the Administration Console and then choose the Groups node. You can also create a new group here. The Membership tab for a group is a little misleading, as it does not let you view the members of the group. To see if a user is a member of a group, you have to select the user and view its Groups tab. WebLogic allows you to add groups to other existing groups, and the Membership tab lists all subgroups that are contained within the selected group. You can also use this tab to add another group to the current group.

Group membership places two important implications on your security configuration. Imagine you’ve defined two groups, A and B, in your domain, where group B is a member of group A. This means that:

  • Every user that belongs to group B also belongs to group A.
  • If you assign a role or policy to group A, all members of group A as well as all members of group B will be assigned the same role or policy.

When you view the Groups tab for a user, the Administration Console lists only the groups that the user belongs to directly. So, if a user belongs to group B, the Administration Console lists only group B under the Groups tab, even though the user actually belongs to both groups A and B.

When you create a new domain using the Configuration Wizard, the following groups are created automatically and are ready for use: Administrators, Deployers, Operators, and Monitors. Initially, the System user is the only user created, and it is also the only member of the Administrators group in the domain.

Remember, groups simply ease the task of administration. If a user is a member of a group, he is not automatically guaranteed any special privileges. A group inherits access privileges only when it participates in a policy statement (either directly or through a role). For example, the initial System user account acquires Administrative access rights only because it is a member of the Administrators group, which in turn is a member of a (global) Admin role, and a policy statement is in place that grants access to all areas of the domain to the Admin role.

Two groups are not listed on the Groups page, but are automatically made available to the security realm:

users
This group represents the set of all authenticated users. Any user that successfully authenticates itself is a member of the users group.

everyone
This group represents the set of all WebLogic users, including anonymous users. Any user, whether authenticated or anonymous, is a member of the group everyone.

These groups provide a convenient way for setting up the default access control. For instance, a resource can be made accessible to all users through the policy statement "User is a member of the group everyone." Alternatively, you can restrict access to only authenticated users by defining the following policy on a resource: "User is a member of the users group." You can also programmatically check for group membership on the server side. The following example checks whether the current user is a member of the users or everyone group:

/** returns false if executed without any security context */
weblogic.security.SubjectUtils.isUserInGroup(
weblogic.security.Security.getCurrentSubject( ),"users");
/** returns true regardless of whether the user authenticates */
weblogic.security.SubjectUtils.isUserInGroup(
weblogic.security.Security.getCurrentSubject( ),"everyone");

Pages: 1, 2, 3, 4

Next Pagearrow