IBM’s WebSphere Application Server for eserver iSeries 400 (formerly named WebSphere Application Server for AS/400) is an e-business application deployment environment built on open standards and is available in two editions. The Standard Edition lets you use Java servlets, JavaServer Page (JSP), and XML to quickly add dynamic content to your Web sites. The Advanced Edition offers all of the functionality of the Standard Edition and additionally supports Enterprise JavaBean (EJB) components.

With WebSphere Application Server, you can secure your applications by configuring three security policies: authentication for determining who is making a request, authorization for determining whether the request is to be honored, and delegation for determining who will be handling the request. Security requirements vary by application. WebSphere allows you to tailor your security policies to match the requirements of individual e-business applications. WebSphere authentication and authorization policies apply to both Enterprise JavaBean and Web resources (including HTML files, JSPs, and servlets), and the same tasks configure security for Web resources and EJBs to provide a unified security model. Resources comprising e-business applications are often distributed across multiple application servers, and those servers may be hosted on different systems.

For such topologies, the WebSphere Application Server provides a distributed security model.

In this article, I’ll provide an overview of WebSphere Application Server security. I’ll also provide instructions for configuring security for a simple application and for a few other tasks related to maintenance and administration.

The instructions for configuring security assume a simple topology consisting of one application server and one Web server, both hosted on the same system, and demonstrate how to configure basic security for a Web client. The WebSphere Application Server supports two client types, a Web client and a Java (EJB) client or applet. Implementing security for a Java client is beyond the scope of this article, though, so this won’t be discussed.

The information presented here is specific to WebSphere Application Server Version 3.5. Though much of this information is also applicable to Version 3.0, I will not attempt to deal with all differences between the two releases; I’ll only note some of the major differences.

Getting Secure

Web clients communicate with a Web server using the HTTP protocol. The WebSphere Application Server provides security services to the Web server via a security plug-in. This plug-in serves as an interface to the security application that resides within the administrative server and helps make security decisions when users request HTML files from the Web server. Security services are provided to the application server via a security collaborator, which serves as an interface to the security application. The collaborator makes security decisions on method calls on EJBs, JSPs, and servlets hosted by the application server. Figure 1 demonstrates the interaction between a security application and the security runtime in the application server and the Web server.

Security policies are configured using the WebSphere administrative console, which is a Java client to the administrative and security applications within the WebSphere administrative server.

An authentication policy determines how authentication is accomplished. Authentication is performed in two steps: first, acquiring the authentication data of a principal; second, validating the authentication data against a user registry.

To understand an authentication policy, you first should be familiar with its components. An authentication mechanism validates authentication data against an associated user registry. The WebSphere Application Server offers two choices for authentication mechanisms: Lightweight Third Party Authentication (LTPA) and native OS. LTPA uses a trusted third-party server to authenticate a user. LTPA is the heart of the distributed security model. Since all application servers trust the third-party authentication server, security information can be passed along with requests from one application server to another. Use the LTPA authentication mechanism when applications are distributed across multiple application servers and the application servers are hosted on different systems. The native OS authentication mechanism uses native OS/400 routines (OS/400 user profiles) to authenticate a user. A native OS is easier to configure than LTPA but can be used only when all application servers are hosted by the same system. Note that authenticating through the native OS mechanism does not log a user onto OS/400. Even though user profiles and passwords are used for authentication, no jobs or threads are executed under users’ profiles.

A challenge type specifies how a server will challenge and retrieve authentication data from a user. The choices for challenge type are none, basic, custom, and certificate. With a challenge type of none, a user is not challenged for authentication data. If the requested resource is protected, then the user will not be served the resource. With the basic challenge type, the user is challenged for a user ID and password. The custom challenge type is applicable only to Web clients and is used when one wants to configure the server to use a customized HTML form to retrieve a user ID and password. The certificate challenge is also applicable only to Web clients. In this case, the user is required to present a digital certificate (X.509) to establish a connection. With the certificate challenge type, the Web server is trusted to authenticate a user through the Secure Sockets Layer (SSL) exchange. Then, for authorization purposes, the WebSphere security infrastructure identifies the principal by extracting information from the certificate and mapping it to an entry in the user registry.

A user registry is where user and group information is stored. It contains a mapping of principals to authentication information and privilege attributes, such as user IDs, passwords, and group IDs.

A principal is a representation of a human user or system entity, such as a server process. The choices for user registry are native OS (which takes advantage of OS/400 profiles) and Lightweight Directory Access Protocol (LDAP) OS/400 Directory.

Secure channel constraint requires an SSL protocol session along with a challenge type to provide data confidentiality and integrity for information flowing between the server

and a Web client. Secure channel constraint may be turned on or off. Dependencies limit how components can be used within an authentication policy. In Figure 2 (page 52), the possible combinations are represented.

The authorization policy determines how authorization is accomplished. Authorization consists of two steps: first, creating permissions and assigning those permissions to principals; second, verifying at runtime that the requesting principal holds at least one of the required permissions.

The WebSphere Application Server authorization model is based on the classic capability model, which is different from the access control model. With the capability model, permissions are associated with a principal. In the access control model, principals and the operations they can perform are associated with the resources themselves.

Resources include Web resources and EJBs. Web resources can only be accessed from Web clients, and for security purposes, each Web resource is represented by a Uniform Resource Identifier (URI). In other words, WebSphere security protects the URI. Since it is possible for a physical resource to be mapped by more than one URI, then one URI can be protected while another URI isn’t. To securely protect a physical resource (such as an HTML file), every URI for that resource must be protected.

With WebSphere Application Server Version 3.x, all Web resources can be protected with a single authorization policy. Any resource actually served by a Web server can be protected by the same authorization policy that protects servlets and JSP files that are served by an application server. However, this will not be supported in future releases. To protect Web resources in versions later than 3.x, those resources must be served by the WebSphere Application Server.

WebSphere security is granular to an enterprise bean home, but not to particular enterprise bean instances. For example, AccountBean is an enterprise bean that encapsulates the account information of account holders. A WebSphere administrator grants Bob access to the AccountBean, so Bob has access to every account in the system. It is not possible to specify that Bob should be able to access only his account and not others. This must be accomplished using application logic. An enterprise bean can belong to multiple enterprise applications.

By default, all enterprise beans are protected and no Web resources are protected when security is enabled. So, until authorization policy is configured, no enterprise bean can be accessed, but all Web resources can be accessed by anyone.

A Web application is a group of servlets that share a common servlet context. A Web application can belong to only one enterprise application. All servlets and JSPs belong to a Web application.

An enterprise application is a collection of Web applications, EJBs, and Web server resources. An authentication policy can be tailored to an application by modifying the challenge type and secure channel constraint values in the enterprise application.

A method group is a collection of {resource name, method name} pairs. For a Web resource, the resource name corresponds with the Web resource, as denoted by its URI, and the method name is an HTTP method. For an enterprise bean resource, the resource name corresponds with either the enterprise bean or its home, and the method name is one of the method names of the enterprise bean or its home.

At configuration time, the names of WebSphere resource methods can be used to determine membership in six predefined method groups. For example, if a method is called getName(), it would be added to the ReadMethods method group if the mapping to the default method groups is applied. Alternatively, the administrator can create new method groups and add methods to those method groups. The default method groups are as follows:

• ReadMethods includes all methods of an enterprise bean that have the prefix get; for example, getName (). For a Web resource, ReadMethods includes the HTTP_GET and HTTP_POST methods.

• WriteMethods includes all methods of an enterprise bean that have the prefix set; for example, setName(). For a Web resource, WriteMethods includes the HTTP_PUT method.

• RemoveMethods includes all remove() methods of an enterprise bean Home. For a Web resource, RemoveMethods includes the HTTP_DELETE method.

• CreateMethods includes all create() methods of an enterprise bean Home.

• FinderMethods includes all findXX() methods of an enterprise bean Home.

• ExecuteMethods includes all methods of an enterprise bean that do not fall under any of the aforementioned categories.

For any given WebSphere resource, a method can be associated with multiple method groups, but all methods must be associated with at least one method group.

A permission is a {enterprise application, method group} pair. To be authorized to invoke a method on a resource, a principal must hold a permission associated with both an enterprise application that contains the resource and a method group that contains the method. Permissions are assigned to privilege attributes (user ID or group ID, for example). The user registry maps principals to privilege attributes. A principal is considered to be holding a permission if that permission has been granted to at least one of its privilege attributes. Since permissions are defined by an enterprise application and a method group, authorization policy is implicitly tailored to applications.

To summarize, authorization policies correlate resources with (enterprise) applications and methods with method groups. Principals are granted permissions that result from these associations, and verification is done at runtime to ensure that the requesting principal holds at least one required permission. See Figure 3.

Delegation involves the use of an intermediary to invoke a method on a target resource on behalf of a requesting client. For example, a client invokes a method on a session enterprise bean that, in turn, invokes a method on an entity enterprise bean. The session bean is acting as an intermediary between the client and the entity bean. A delegation policy determines the identity under which the intermediary operates on behalf of the client.

In the WebSphere Application Server, the delegation policy is determined by values associated with the methods of the enterprise bean. The initial values are retrieved from the deployment descriptors of a bean but can later be modified by an administrator. Delegation policies can be applied jointly to all the methods in a bean or separately to individual methods.

A delegation policy is created by setting the values of one (or two) attributes: Run- As Mode or Run-As Identity. The Run-As Mode attribute determines the identity under which methods are to be run. The valid values are CLIENT, SYSTEM, and SPECIFIED. The Run-As Identity attribute specifies the principal when the Run-As Mode is SPECIFIED. This value must be selected by an administrator from an identity associated with one of the enterprise applications that contains the enterprise bean. When the authentication mechanism is native OS, the effective Run-As Mode is always SYSTEM, regardless of the value that is specified. LTPA supports all three values.

To sum up, WebSphere applications can be secured by configuring three policies: authentication, authorization, and delegation. Two authentication mechanisms are offered: native OS and LTPA. The native OS mechanism can only be used when all application servers are hosted by the same system. LTPA is the choice when application servers are hosted by different systems. Authorization is based on the capability model. This differs from the access list model, as permissions are associated with a principal in the capability

model, while in the access control model, principals and the operations they can perform are associated with the resources themselves.

Delegation is defined in terms of the Run-As Mode and Run-As Identity attributes assigned to EJBs. Authentication policy can be partly tailored to an application by modifying the challenge type and secure channel constraint settings for enterprise applications, while authorization policies are implicitly tailored to individual applications. The LTPA authentication mechanism is the heart of the distributed security model, providing a third-party security server that all application servers trust.

This overview, together with the Web sidebar “A WebSphere Configuration Scenario: Configuring Security” (posted at www.midrangecomputing.com/mc), which includes the instructions for enabling security and configuring a simple application, provides you with a good start but only begins to scratch the surface of WebSphere’s security features. Additional topics you may wish to investigate include enabling security for Java clients, single sign-on, HTTP session security, and programmatic support for login.

REFERENCES AND RELATED MATERIALS

• Extending WebSphere Applications for Business-to-Business Integration—AS/400 Edition: www.as400.ibm.com/ebusiness/expreport/wsappextend.htm
• IBM WebSphere page: www.iseries.ibm.com/websphere
• “IBM WebSphere Standard/Advanced 3.5 Security Overview,” Gennaro Cuomo, Don Ferguson, Michael Fraenkel, Rob High, and Nataraj Nagaratnam (available at www.ibm.com/software/webservers/appserv/security_v35.pdf)

Web Client Java Client HTML IIOP

Security Plug-in

Web Server WebSphere Application Server Web Server

Resources

HTML WebSphere

Resources

EJBs Servlets JSPs

Figure 1: Security policies can be configured to protect Web server and WebSphere resources.

OSE

Security Application Security Collaborator

Challenge Authentication User Client Type Mechanism Registry

None None None Web, Java

Basic LTPA LDAP Web, Java

Basic Native OS Native OS Web, Java

Certificate LTPA LDAP Web

Custom LTPA LDAP Web

Figure 2: Dependencies limit how components can be combined to form authentication policies.

Permission

Resource Method

Figure 3: Principals are granted permissions that result from associations involving applications, resources, methods, and method groups.

Principal

Enterprise Application

Method Group