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

advertisement

AddThis Social Bookmark Button O'Reilly Book Excerpts: WebLogic: The Definitive Guide

Java and Security, Part 1

by Avinash Chugh, Jon Mountjoy and

Related Reading

WebLogic: The Definitive Guide
By Jon Mountjoy, Avinash Chugh

Editor's note: In part one in a two-part series of excerpts from Chapter 17 of WebLogic: The Definitive Guide, authors Avinash Chugh and Jon Mountjoy examine WebLogic's various security mechanisms, beginning with a look at the Java Security Manager and how WebLogic filters connection requests. They also cover WebLogic's authentication and authorization framework and how it supports the standard J2EE security services.

WebLogic provides a comprehensive suite of security services that can be used to protect all aspects of a domain and its deployments. These security services affect all aspects of your domain: from the lowest level provided by the Java Security Manager, to connection-level security, to application-level security in which you can protect your administered and deployed objects (such as EJBs, web services, and JDBC pools), and finally to domain-level security in which you can establish trust between two domains. These security services target three distinct sets of users: application developers who can use the services to secure their applications; administrators who need to configure security for the system and deployments; and security vendors or customers who can change and extend the facilities provided by WebLogic.

Let's begin at the JVMlevel. Here, the Java Security Manager uses a security policy file to restrict access to specific runtime operations. This ensures that programs running on the JVM, including WebLogic Server itself, can access protected resources in permitted ways only. For instance, you can configure the Java Security Manager so that all Java threads have write-access only to specific directories in the filesystem. WebLogic enhances the Security Manager by allowing you to define additional security policies for resource adapters and EJBs, thereby ensuring that these components have access to defined resources only. There are also other global, higher-level security permissions that apply to these resources and application code.

WebLogic can filter connection requests from clients. A connection filter defines rules that determine what basis the server accepts or denies client connections. These rules are based on several parameters: typically, the client's IP address and port; the protocol used to establish the connection; and the server's listen address and port. You can assign multiple connection filters to a server, or perhaps even write your own connection filter class that implements custom filtering logic. Using connection filters, you can easily ensure that the server accepts only T3 connections from within your intranet, for example. SSL security is another mechanism available at the socket level, which we encountered in Chapter 16. SSL protects network communication provided through its support for data integrity, confidentiality, and authentication.

WebLogic provides partial support for standard JAAS. The JAAS framework is a standard extension to J2SE v1.3 and is now part of the J2SE v1.4 platform. Authentication enables the server to verify the identity of the user who is running the Java code, whether it is an applet, servlet, EJB, or application. Authorization is the server's ability to enforce access control based on the user's identity, security privileges, and policies. WebLogic allows Java clients to use JAAS authentication, and login modules are implemented using JAAS. If you need to use JAAS authorization, you will have to code your own schema above WebLogic's infrastructure.

WebLogic's security infrastructure is founded on a set of modular, extensible security service provider interfaces (SSPIs). This architecture allows you to plug in new security providers, swap out old ones, and run WebLogic's default providers alongside your own. Your WebLogic distribution is equipped with a set of security providers that provide the default implementations for the SSPIs. WebLogic's security providers implement the underlying security framework for your J2EE applications. That is, the standard J2EE-defined security mechanisms are implemented (and extended) through the SSPIs. Often, WebLogic's security providers will refine the existing security constraints. For instance, the standard ejb-jar.xml deployment descriptor allows you to restrict access to an EJB method to authenticated users in a specific role. WebLogic allows you to refine this constraint by ensuring that the user has access only during certain times of the day. In fact, the SSPIs are an open architecture, and you can easily plug in a third-party security provider from a security vendor. Alternatively, you can build new security services by implementing your own security providers.

WebLogic's default security providers are quite versatile. A security realm is a logical grouping of users, groups, roles, and security policies, along with the complete set of security providers. Security policies assigned to server resources can be used to determine who is authorized to access the resource. WebLogic lets you protect a whole range of resources: individual EJB methods, a web application, a collection of web pages, connection pools, data sources, or any administered object. You even can protect a branch within the JNDI tree, thereby preventing unauthorized clients from looking up objects in the JNDI tree. All this security data is stored in an embedded LDAP server. WebLogic also can be configured to use an external LDAP repository, such as Open LDAP, Active Directory, or Novell NDS. These external repositories can be used for authentication only, not authorization.

Finally, WebLogic allows you to set up a trust mechanism between two domains. This ensures that authenticated users from one domain can then access resources in another domain.

This chapter examines all of these security mechanisms. Although they are all quite different from each other, they complement each other quite well. We begin with a look at the Java Security Manager and how WebLogic is able to filter connection requests. We then examine WebLogic's authentication and authorization framework and learn how it supports the standard J2EE security services. We also coverthe various security providers available within a security realm and their default implementations. Finally, we end with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion providers.

The Java Security Manager

At the JVMlevel, WebLogic can use the standard Java Security Manager to prevent untrusted code from performing unwanted actions. Using a security policy file, you can configure the JVMso that all threads running on the JVMhave restricted access to sensitive runtime operations. The security policy file encapsulates a set of permissions that are granted to (or revoked from) all classes loaded within the current instance of the JVM. You can define a whole range of security permissions to control access to particular resources—e.g., "write" access to certain folders on the filesystem, "connect" access to a particular host and range of ports, "read" access to environment variables, "get" access to the current class loader, and more. Refer to your JDK documentation for more information on the Security Manager and security policy files.

Java's Security Manager ensures that any code running within WebLogic accesses these critical resources only in the permitted ways. This low level of access control may be useful for third-party untrusted code. The Java Security Manager also can interact with J2EE deployment settings. For instance, you can use the standard ra.xml deployment descriptor to define security permissions that apply to the resource adapter. WebLogic also provides similar access control for web applications and EJBs.

Note that WebLogic itself requires a policy file to be in place before it can run. The startWebLogic scripts load the policy file located at WL_HOME/server/lib/weblogic. policy by default.

Configuring the Security Manager

In order to use the Java Security Manager, you need to supply two options from the command line when starting WebLogic Server:

  • You must use the –Djava.security.manager option to ensure that the default security manager is installed, and that the JVM is subjected to policy checks.
  • You must use the –Djava.security.policy option to specify the location of a security policy file.

By default, the JVMuses security policies defined in the java.security and java.policy files located under the JAVA_HOME/jre/lib/security folder. Here is the syntax for starting WebLogic Server using a custom security policy file:

java –Djava.security.manager –Djava.security.policy==c:\oreilly.policy
  ... weblogic.Server

The default startup scripts created by WebLogic refer to the sample security policy file located at WL_HOME/server/lib/weblogic.policy. Notice how we've used the == (double equal sign) when specifying the java.security.policy argument. This persuades the Security Manager to use c:\oreilly.policy as its only source of policies. If we had used a single equal sign instead, the policy file would be used in conjunction with default security policy files provided by your JDK installation.

Usually the JVMwill use the security policy file to enforce access control over any code running within WebLogic. The only deviation from this rule is when WebLogic Server starts up. When a server boots up, WebLogic partially disables the Java Security Manager and replaces it with a variation that disables the checkRead( ) method. While this approach improves the performance of the startup sequence, it also reduces the security of the JVMduring startup. In addition, it means that the startup classes for WebLogic will run using this modified security manager. You will need to ensure that these classes cause no security breaches.

Note: Because the policy file determines access privileges for all classes running within WebLogic's JVM, we recommend that only the Administrator has read and write access to the security policy file. No other users should be allowed to access the policy file.

Global Security Policies

WebLogic allows you to define security policies for EJBs, resource adapters, and web applications in the weblogic.policy file. Table 17-1 lists the codebases under which the default permissions for these component types may be defined.

Table 17-1. Default codebases for access permissions that apply to J2EE components

Application typeCodebase
EJBsfile:/weblogic/application/defaults/EJB
Resource adaptersfile:/weblogic/application/defaults/Connector
Servletsfile:/weblogic/application/defaults/Web

You can use these codebases to grant special privileges to particular J2EE component types. Note that any security policies defined under these codebases apply to all EJBs, resource adapters, and web applications deployed to that particular server instance.

Application-Specific Security Policies

You also can define security policies that are specific to an EJB component or resource adapter, and thereby ensure that only particular components are targeted. To achieve this, you must modify their deployment descriptors, and not the policy file itself. Resource adapters support this mechanism as part of the J2EE standard, and you need only modify the standard ra.xml descriptor file. For EJBs, you need to modify the weblogic-ejb-jar.xml descriptor file. In both cases, it is the securitypermission element that allows you to define additional security policies.

Let's look at specifying permissions for EJBs. The security-permission element in the weblogic-ejb-jar.xml descriptor specifies security privileges that apply to all EJBs packaged in the EJB JAR. The following example grants read and write access to a temporary directory on the server's filesystem for the EJBs:

<weblogic-enterprise-bean>
 <!-- webLogic enterprise bean statements go here -->
</weblogic-enterprise-bean>
<security-role-assignment>
 <!-- the optional security role assignments go here -->
</security-role-assignment>
<security-permission>
 <description>
  grant permission to special folder
 </description>
 <security-permission-spec>
  grant {
   permission java.io.FilePermission
    "f:${/}tmp${/}-", "read,write";
  }
 </security-permission-spec>
<security-permission>

Notice how the security-permission-spec element defines a grant permission using the same syntax for security policy files. The only restriction to this syntax is that you cannot use the codebase or signedBy clauses.

Tracing the Security Manager

BEA provides a Recording Security Manager that can be used to trace any permission problems caused by the Java Security Manager. When installed, the tool detects and records all access control exceptions that occur at runtime. In this way, you can easily pinpoint problems in your access control policy and later reconfigure the security policy to remove these errors. The tool is not distributed with WebLogic Server. However, it can be downloaded from BEA's dev2dev web site (http://www.dev2dev.bea.com).

Connection Filtering

At the connection level, WebLogic provides two security features: filtering and SSL. Chapter 16 provides a detailed look at SSL. Let's take a look at connection filtering here. A connection filter allows the server to reject unwanted connections based on some criteria. For example, a connection filter would allow you to configure WebLogic to permit T3 or IIOP connections only from within your intranet, and reject any T3 or IIOP connection request from outside the intranet. So, connection filtering provides network-level access control.

WebLogic comes equipped with a default connection filter that examines one or more connection filter rules defined in the Administration Console. Alternatively, you can create your own custom connection filter that evaluates the basis that incoming connections are accepted by the server. A custom connection filter is a Java class that implements WebLogic's ConnectionFilter interface. The interface is dead simple—the class must implement the accept() method, which simply throws a FilterException to indicate that an incoming connection request should not be allowed through. Here is an example of a connection filter that refuses T3 connections from hosts unless their IP address matches 10.*.*.*:

import weblogic.security.net.*;

public class MyConnectionFilter implements ConnectionFilter {
 public void accept(ConnectionEvent evt) throws FilterException {
  if ( evt.getProtocol( ).equals("t3") ) {
   byte [] addr = evt.getRemoteAddress( ).getAddress( );
   if ( !(addr[0]==10))
    throw new FilterException( );
  }
 };
}

This filter simply throws a FilterException whenever the filter criteria have been violated. If the method completes without throwing any exceptions, the connection is allowed through. The method receives a single parameter, a ConnectionEvent object, that encapsulates vital information about the connection request. Typically, you will use this information to implement the acceptance criteria for the filter. The ConnectionEvent class provides various methods to access this information:

getProtocol()
Retrieves a string value that represents the protocol used to establish the connection.

getRemoteAddress()
Retrieves a java.net.InetAddress object that represents the client’s address.

getRemotePort()
Returns the client's port number used to establish the connection.

getLocalAddress()
Retrieves a java.net.InetAddress object that represents the server’s listen address.

getLocalPort()
Obtains the server's port number to which the connection is being made.

Once you have compiled the filter class, you need to install it. First, you need to ensure the class can be located from the server's classpath. Then, using the Administration Console, expand the topmost node indicating your domain and choose the View Domain-Wide Security Settings option. The Configuration/Filter tab contains the settings for connection filters. WebLogic 7.0 users should select the Security/Filter tab after expanding the domain node from the left pane.

Enter the name of your connection filter class in the Connection Filter setting. You will also notice the Connection Filter Rules setting. Use this option if your filter class also implements the optional ConnectionFilterRulesListener interface. In this case, the connection filter will be able to receive and process filter rules defined in the Administration Console.

Pages: 1, 2, 3, 4

Next Pagearrow