J2EE Security Model

The security model within J2EE is a continuation of the J2SE security model. In the J2SE model, one of the primary focuses of the security policy is based on where the code is located or who has signed the code with a digital certificate. In the J2EE model, the focus is on who is executing the code or, rather, who is remotely invoking the server-side code. This paradigm shift makes sense because J2EE code runs within a container located in the application server, which is in a secure location and controlled by IT personnel. The application deployer and administrator will decide what application code to deploy on this server. Potentially every user of the application will have access to this code and usually this is not within the security expectations of the application. The concern here is thus not so much untrusted code, but rather untrusted users.

Users

A user is considered any entity that is accessing a J2EE application. Sometimes a user is an actual person and other times it is a client application or another application server. A user must be identified through some credentials. This is confidential information that they should be in possession of, such as a username and password or a digital certificate. When attempting to sign on to a J2EE application, the user presents the credentials and the J2EE application server or the application code then matches the information with a pre-registered user. From this point forward, application code is now designated as running under that user's control.

It is important to understand that a J2EE user is not the same thing as a user in another context. J2EE users are separate entities than users defined in operating systems, databases, EIS instances, mainframes, and other applications. In typical enterprise applications, J2EE users must be mapped to users in other systems and this mapping can be specified in different ways.

Groups

J2EE groups represent an efficient way of categorizing sets of J2EE users with similar characteristics, such as working in the same department or location, having the same job title, or reporting to the same manager. As the number of users grows, specifying security policies on an individual basis becomes prohibitively time-consuming and error-prone. Security policies assigned at a group level allow large numbers of user security policies to be set simultaneously, reducing the amount of work required by an application administrator. Creating the correct grouping structure for your users is an important step in setting and maintaining user level security.

Roles

J2EE roles represent a type of functionality that one or more users or groups have in common. Some examples are the ability to change budget information, the ability to return merchandise, and the ability to change an organization's chart of employees. When developers create code that will be restricted, they assign roles to that code. Only users and groups that are assigned to that role should be able to execute this code. When the code is deployed, these roles will then be associated with actual users and groups. By associating the code with roles instead of actual users, the developer creates a level of abstraction that allows the group to be portable across multiple environments, departments, and even companies.

For example, suppose that a servlet has been created for changing the organization chart of a company. Because this code should not be executed by just anybody, it is considered a restricted resource and assigned to the role of OrgChartModifier. This servlet is packaged as third-party software and sold to other companies. When those companies deploy the servlet, they associate actual users and groups that have the ability to change the organization chart with the role of OrgChartModifier. This is depicted in Figure 27.1.

Restricted Resources

By default, every resource within a J2EE application can be executed or accessed by any user. The Web container and the EJB container will allow anybody to access a JSP or HTML file, execute a method on a servlet or an EJB. If the EIS tier is set up to connect with an EIS instance using a specific authentication policy, access to that instance will be granted to every user. Although this might not sound completely unreasonable in a controlled environment such as a small department within a company, it is a recipe for chaos on the public Internet.

Most Web applications have a combination of restricted and public resources. Anonymous application clients are allowed to perform certain unrestricted actions, such as browsing a catalog, requesting product information, and possibly creating an anonymous shopping cart. However, within the course of their visit, many Web sites will ask the user to identity herself. This will occur when the user is requesting a controlled resource. Examples of this are checking out a shopping cart and accessing member or subscription holder information. If a user does not have the proper authorization to access a requested resource, he might be notified as shown in Figure 27.2.

Declarative security through deployment descriptors allows developers and deployers to protect access to EJB methods, access to Web application components (servlets, JSPs, HTML pages, and so on), and access to EIS instances (for example, SAP and PeopleSoft).

The Web Application Deployment Descriptor

Every Web application running in a J2EE application server must be associated with a web.xml file. This XML file has an accompanying DTD that can be found at http://java.sun.com/dtd/web-app_2_3.dtd. The web.xml file offers a vendor-neutral method for specifying many attributes about a Web application, including authentication method, name of application welcome page, and security constraints. Web applications running on BEA WebLogic Server can also specify additional information in accompanying WebLogic-specific deployment descriptors. Although these files can potentially hold a lot of information, this chapter and the following one will describe with a few of their attributes that relate to security.

Authentication

The act of asking clients to identify themselves is referred to as authentication. This involves asking the client to present some secret information of which only it is in possession. The most common form of this is a username and a password. However, this information can take other forms, such as digital certificates, smart cards, and biometric-based methods such as fingerprinting, voice recognition, and fingerprinting. Authentication of Web users is performed differently from non-Web users. Authentication of non-Web users is discussed later in this chapter in the section titled "Java Authentication and Authorization Service."

The J2EE specification states that an application server must be able to authenticate its Web users in three ways. Consequently, in addition to other techniques, WebLogic Server can authenticate users in the following ways as well:

• HTTP basic authentication— This type of authentication uses the browser's built-in identification dialog. This provides developers with a quick and dirty method of asking users to identify themselves. It requires no additional code, but the look of the dialog cannot be changed. After the user enters his information and presses the submit button, his username and password are Base64-encoded and sent to the server. An example of this is shown in Figure 27.3. Unfortunately, Base64 encoding is not the same as encryption. This means that the user's information is essentially sent in the clear and can be viewed by packet sniffers.

  Figure 27.3. Web browsers have the built-in capability to display a dialog that requests a username and a password.

  

  A variation of basic authentication is digest authentication. Digest authentication does not transmit user names and passwords in clear text. Rather, it uses a message digest. A message digest is a fixed-length encoding of some information that uses an algorithm for encryption. The default algorithm is MD5. MD5 produces a 128-bit hash of the original data and is high speed. WebLogic Server supports the MD5 and Secure Hash Algorithm (SHA) message digest algorithms. SHA is more secure and produces 160-bit hashes but is slower than MD5.

• Form-based authentication— Form-based authentication allows a Web page to collect identification information from a user. This requires more work because the Web page has to be created. However, the user is presented with a more visually appealing user interface. An example of this is shown in Figure 27.4. As in HTTP basic authentication, this information will be sent to the server without being encrypted.

  Figure 27.4. Form-based authentication allows the login process to be customized with a look and feel similar to the rest of the Web site.

  

• Client certificate authentication— This type of authentication involves encryption by default and uses a server and optionally a client digital certificate to negotiate encryption keys. After this negotiation takes place, the rest of the user session takes place using SSL over HTTP (HTTPS). A server-side certificate is used to encrypt the communication, and a client-side certificate is used to authenticate the user. When using only a server-side certificate, the user still needs to be authenticated.

How Is the Authentication Method Specified?

Within the web.xml file, the XML element named <login-config> is used to specify the basic authentication method to be used by a Web application. Within this element are other elements named <auth-method>, <form-login-page>, <form-error-page>, and <realm-name>. Listings 27.1, 27.2, and 27.3 illustrate how to establish the authentication method for Web users of Web applications.

Listing 27.1 Example of Using http-basic Authentication

<login-config>
 <auth-method>BASIC</auth-method>
 <realm-name>myrealm</realm-name>
</login-config>

Listing 27.2 Example of Using Form-Based Authentication; Notice That Both the Login Page and a Login Error Page Must Be Stated

<login-config>
 <auth-method>FORM</auth-method>
 <form-login-config>
  <form-login-page>/login.jsp</form-login-page>
  <form-error-page>/loginerror.html</form-error-page>
 </form-login-config>
</login-config>

Listing 27.3 Example of Using Client Certificate Authentication

<login-config>
 <auth-method>CLIENT-CERT</auth-method>
</login-config>

The Administration Console or WebLogic Builder tool can be used to change these settings, which are reflected inside a Web application's web.xml file. To accomplish this using WebLogic Builder, open a Web application using the File menu Open option as illustrated in Figure 27.5.

This will open a new window allowing various ways to configure your Web application. Click on the Web application name in the left panel and then take note of the Login tab in the right panel, as shown in Figure 27.6.

After clicking on the Login tab in the right panel, you will be presented with a screen to input your login configuration for the Web application as shown in Figure 27.7.

After setting the login configuration, or anything else in web.xml or WebLogic Server–specific weblogic.xml deployment descriptors, you must save these changes back to the XML files. Simply click the File menu's Save option as shown in Figure 27.8. You can also archive your changes back to a WAR file by clicking on the File menu's Archive option, which is also shown in Figure 27.8.

How Is Security Specified?

J2EE applications can delineate restricted resources and those users who have access to them in two ways: declarative security and programmatic security. However, within a single application, both methods of security delineation can be employed. This section discusses both declarative and programmatic security. It discusses how each method works, when to use each, and their advantages and disadvantages.

Declarative Security

The standard method of declaring who can access restricted resources is accomplished through XML-based deployment descriptors created by J2EE application developers. When developers create their respective EJBs, servlets, JSPs, Java classes, and other resources that are part of applications, the developers must indicate where access will be restricted. The application deployer then takes these descriptors and modifies them to work within the WebLogic Server runtime environment.

When declarative security is employed, the J2EE container is required to enforce this security. If the client is attempting to access a restricted resource or to execute a restricted method of an EJB, the container must first verify that the client has been authenticated and then make sure that they are in one of the roles that has been authorized access to that EJB's method.

The advantages of using declarative security are that security restrictions to existing code can be modified in XML-based deployment descriptors without changing and recompiling application code. This is significant because changes in application code are more likely to produce unexpected insecure side effects than are changes to deployment descriptors. Declarative security is much easier to deal with in the modification and maintenance of Web applications.

J2EE Web Components

Security constraints are set up on a Web application–level basis, as specified in the web.xml and weblogic.xml deployment descriptor files. Within web.xml, restricted resources such as servlets, JSPs, and HTML pages are referenced by specific URLs or URL patterns, the HTTP method that is used to access them, and the user roles that are allowed access.

Within the web.xml file, security constraints are specified within the XML element named <security-constraint>. Within this element are other elements named <web-resource-collection>, <auth-constraint>, and <user-data-constraint>. The weblogic.xml deployment descriptor file is used to link user roles as specified in web.xml with principals as specified in a WebLogic Server security realm.

Listing 27.4 shows a sample web.xml file containing a set of URLs that have been marked as restricted. As specified in the <url-pattern> tag, these URLs are all located in or below the /pages/managers directory. The manager and systemadmin roles have been defined to be allowed access to these URLs if they use an HTTP Get method. Notice that these roles must be defined within a <security-role> tag. In weblogic.xml, these roles will be associated with actual WebLogic Server users and groups.

The <transport-guarantee> tag specifies whether these resources will be protected with encryption. Possible values are NONE, INTEGRAL, and CONFIDENTIAL. NONE means that these resources can be accessed using the standard HTTP protocol. INTEGRAL indicates that a request to these URLs should be sent in a way that it could not be changed in transit. CONFIDENTIAL indicates that the request should be encrypted. The use of INTEGRAL and CONFIDENTIAL usually indicates that the HTTPS protocol (SSL over HTTP) will be required to access these resources.

Listing 27.4 A Sample web.xml File with Security Constraints

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN'
 'http://java.sun.com/dtd/web-app_2_3.dtd'>
<web-app>
<security-constraint>
 <web-resource-collection>
  <web-resource-name>ManagerResources</web-resource-name>
  <description>
   Only managers are allowed access to these resources.
  </description>
  <url-pattern>/pages/managers/*</url-pattern>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <description>
   The following roles have access to these pages
  </description>
  <role-name>manager</role-name>
  <role-name>systemadmin</role-name>
 </auth-constraint>
 <user-data-constraint>
  <description>
   This is how the user data must be transmitted
  </description>
  <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>
</security-constraint>

<security-role>
 <role-name>manager</role-name>
 <role-name>systemadmin</role-name>
</security-role>

</web-app>

In addition to manually changing the web.xml file, you can use the Administration Console or WebLogic Builder tool. When using the WebLogic Builder tool, select the Web application you are interested in, as illustrated in Figure 27.5. You must also link roles defined in web.xml to users and groups (principals) defined in WebLogic Server. This is done is weblogic.xml. An example of this is shown in Listing 27.5.

Listing 27.5 A sample weblogic.xml File That Assigns the Roles of manager and systemadmin to Users and Groups Within WebLogic Server

<!DOCTYPE weblogic-web-app
 PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
 "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

<weblogic-web-app>

 <security-role-assignment>
  <role-name>manager</role-name>
  <principal-name>johnq</principal-name>
  <principal-name>managergroup</principal-name>
 </security-role-assignment>

 <security-role-assignment>
  <role-name>systemadmin</role-name>
  <principal-name>carlw</principal-name>
  <principal-name>jaimem</principal-name>
  <principal-name>systemadmingroup</principal-name>
 </security-role-assignment>
</weblogic-web-app>

Modification of security roles may also be performed through the Administration Console or WebLogic Builder tool. While editing a Web application through the WebLogic Builder tool, click on the Security Roles option in the left panel, as shown in Figure 27.9.

By clicking on the Add button in the right panel shown in Figure 27.9, a window will pop up and enable you to then add new roles and add principals to those roles, as illustrated in Figure 27.10.

Enterprise JavaBeans

EJBs are deployed in EJB JAR files, separate from the WAR files that hold Web container components. They are also executed in their own container environment. EJBs can potentially be accessed from components in many different Web applications. The security constraints of EJBs are specified on a bean-by-bean basis.

According to the J2EE specification, every deployed EJB must have an associated ejb-jar.xml file. This file is used to specify many attributes about the EJB, including security constraints. The DTD for this file is located at http://java.sun.com/dtd/ejb-jar_2_0.dtd.

Within the ejb-jar.xml file, you use the XML element named <method-permission> to restrict execution rights of an interface method to one or more specific user roles. WebLogic also uses a weblogic-ejb-jar.xml file to specify WebLogic Server–specific EJB information. In the context of security, client authentication information for EJBs accessed using IIOP can be specified.

Listing 27.6 contains part of an ejb-jar.xml file that sets the security restrictions for an EJB. In this example, the security role named manager is allowed to access any method of the WithdrawFunds EJB.

Listing 27.6 A Sample ejb-jar.xml File Snippet with Security Constraints

<security-role>
 <role-name>manager</role-name>
</security-role>
<method-permission>
 <role-name>manager</role-name>
 <method>
  <ejb-name>WithdrawFunds</ejb-name>
  <method-name>*</method-name>
 </method>
</method-permission>

Just as weblogic.xml is used to associate security roles in web.xml with users and/or groups in WebLogic Server, weblogic-ejb-jar.xml is used in combination with ejb-jar.xml. An example of this is shown in Listing 27.7.

Listing 27.7 A Sample weblogic-ejb-jar.xml Snippet to Associate ejb-jar.xml Security Roles with WebLogic Server Users and/or Groups

<security-role-assignment>
 <role-name>manager</role-name>
 <principal-name>johnq</principal-name>
 <principal-name>managergroup</principal-name>
</security-role-assignment>

Information in ejb-jar.xml and weblogic-ejb-jar.xml files for deployed EJBs can also be modified with the Administration Console and WebLogic Builder tool. You first load an EJB JAR or J2EE EAR file into the WebLogic Builder. In Figure 27.11, we have opened a J2EE EAR file that is associated with an EJB JAR file. After opening the J2EE EAR file properties in the WebLogic Builder tool and selecting an EJB JAR file, we can add roles to the deployment descriptor for the EJB JAR file as illustrated in Figure 27.11.

After selecting an EJB within an EJB JAR file, select the Methods option in the left-side panel for that EJB, as illustrated in Figure 27.12. Then select the Permissions tab in the right-side panel also as illustrated in Figure 27.12. It is here that you can set security properties for an EJB.

After selecting the Add button in the right-side panel as shown in Figure 27.12, a window will pop up as shown in Figure 27.13. It is within this window that you specify which roles have access to which methods on the particular EJB.

EIS Tier

Declarative security to EIS instances is set with deployment descriptors that are packaged with resource adapters. According to the J2EE specification, every deployed resource adapter must have an associated ra.xml file. Within this file is an XML element named <authentication-mechanism>. This element denotes how clients will authenticate themselves and is specific to the EIS instance. Possible mechanisms include username and password, digital certificates, and Kerberos ticketing. Other elements such as <credential-interface> and <security-permission> are used to declare EIS security. An example of this is in Listing 27.8.

Listing 27.8 A Code Snippet from ra.xml That Illustrates How to Specify Authentication Using Passwords

<authentication-mechanism>
 <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
 <credential-interface>javax.resource.security.PasswordCredential</credential-interface>
</authentication-mechanism>

Programmatic Security

Using declarative security can be too restrictive for some situations. For example, security requirements of an application might involve roles that are dynamic. One case of this would be giving frequent, high-spending customers first access to new products. If these products are viewed and purchased using specific servlets and JSPs, the components should be restricted to only those customers. Unfortunately, the criteria used to judge who these customers are can change over time (for example, the criteria of more than 50K annual purchases might change to 100K). Also, as customer activity changes, the membership of this group changes as well (for example, Joe's SuperStore places a 37K order and it is now in this group). Declarative security is not flexible enough to accommodate this type of security.

With this flexibility comes the price of having to modify, recompile, and redeploy code whenever the business rules concerning application security policies changes. However, as we will see later in this chapter, WebLogic also has some built-in mechanisms for dynamic security policies that do not require changes to application code.

When programmatic security is employed, the hosting container will not attempt to enforce security because it has no idea what your security requirements are. This job is left up to the application component code.

J2EE Web Components

Programmatic security is available for servlets and JavaServer Pages. Both have access to a HttpServletRequest object when accessed in the context of a client request. The HttpServletRequest object contains these methods relating to users, roles, and principals.

• getRemoteUser()— Returns the login name of the client making this request or null if the client has not been authenticated

• getUserPrincipal()— Returns a java.security.Principal with the name of the client making this request or null if the client has not been authenticated

• isUserInRole()— Returns a boolean indicating whether the user is a member of a specified role

Using these methods and associated business logic, it is possible to come up with a dynamic security mechanism that meets your design requirements.

Enterprise JavaBeans

Programmatic security is also available for EJBs through the use of the EJBContext object. This object has two methods related to users, roles, and principals that act like the HttpServletRequest methods in the previous section:

• getUserPrincipal()

• isCallerInRole()

When used in combination with business logic, dynamic security can be customized to meet just about any design specification.

EIS Tier

Whether an EIS instance is being accessed by a servlet, JSP, or EJB, the user, role, and principal information will be available to the calling code. This code will then be responsible for taking this information and logging in to the EIS instance. The calling code will include EIS instance signon code and the EIS tier container will not be responsible for creating connections to EIS instances. The EIS resource adapter will accept client credentials and attempt sign on.