The WebSphere Security Model

It is widely accepted that the strongest defense is a 'layered defense'. The WebSphere security model provides a layered defense to protect your resources. What we mean by this is that security policy can be enforced in WebSphere at each container and network boundary. Thus, if someone manages to hack into the router or web server, they will be challenged and restricted at the web container, and again at the EJB container, and again at the data system, and so on.

While WebSphere itself is focused on protecting those resources hosted in the WebSphere runtime – JSP pages, servlets, EJBs, and so on – it is designed on open standards and with an eye toward being able to federate with enterprise security providers that can protect your entire system.

As we've indicated earlier, the security system in WebSphere is controlled through security policies that are declared and administered outside the application implementation. Having said that, there are times when you just want to have more control than that embedded in your business logic, or perhaps to overcome existing limitations in the security capabilities of WebSphere. While these are few, they nonetheless can be important.

Two things that you may want in the way of security are instance-based authorization and credential mapping. Neither of these are supported in the version 5.0 of WebSphere and so you will have to code this into your application if you need either of them. See the sections on Credential Mapping and Instance-Based Authorization, for more discussion on these topics.

Enabling Security

Security in WebSphere is controlled first from a global security switch on the admin console. You need to turn security on before WebSphere will begin protecting its resources. If you do not, WebSphere will allow any request to be invoked on any resource in the system:

Security is enabled on the Admin console in the Global Security Configuration panel under the Security Center.

Once you've enabled the global security option, then you can begin to define security policies to govern the rest of your system. The following checklist gives you an outline of the activities you should perform to fully enable a secure WebSphere environment for your applications:

• Enable the global security configuration option (as indicated above). At the same time you should:

  • Indicate what type of authentication you want to use throughout the system

  • Configure the user registry, level of message protection, and level of trust establishment you want to use (it is generally a good idea to configure your user registry before you attempt to enable global security as the configuration validation may prevent you from turning on security before you've configured the registry)

• Ensure sensitive system runtime files are properly protected

• Acquire and distribute signed SSL certificates for each of your application servers

• Add any additional users to your user registry

• As you build your applications, define web resource collections, security constraints, method permissions, and user roles and deploy that information

• Configure the data sources and other resources that you will use in your application, setting any credential information the system will need to access those resource managers for your application

• Set authorization policies establishing who can access which role

How you perform these tasks will be described in more detail throughout the rest of this chapter.

Challenge Mechanisms and Controls

Before we get too far into the specifics of the system it helps to remember that there are several ways that you may enter a WebSphere network. The most obvious point of entry is from your browser, pointing it to a web site with a specific URL. Other points of entry include fat J2EE or CORBA clients, JMS clients (both consumers and suppliers of messages), and web services clients.

From an end-user point of view it all starts when you attempt to access a protected resource and are prompted to authenticate yourself. Each point of entry into the system offers a slightly different variety of options for authenticating you and using that to protect the system. These differences are driven by the differences in scenarios and expectations that each entry approach is intended to support.

Web Clients

For web applications, where the point of entry is from a web browser via HTTP, the authentication challenge is driven by J2EE deployment policy specified for the web application being accessed. See the Establishing Trust in the User section for more information on how these deployment options work. These policies can be specified during the application assembly or deployment processes.

J2EE and CORBA Clients

For EJBs being access from fat J2EE or CORBA clients, the authentication challenge is controlled with configuration options associated with the application server through system management. WebSphere supports two basic authentication protocols over IIOP for J2EE and CORBA clients. The "IBM" protocol is a proprietary protocol used in earlier versions of WebSphere and continues to be supported for backwards compatibility with those versions and products that supported earlier WebSphere clients.

The "CSI" protocol refers to the CORBA Common Secure Interoperation (Version 2 – CSIv2) protocol. This is a standard protocol that is now mandated by the J2EE 1.3 specification for secure interoperation with other vendor application servers. If you will be operating a mixed network of both version 5.0 and a version prior to version 5.0 application servers or clients, then you should select both CSI and SAS protocols. Otherwise, if you will be operating a network of just WebSphere version 5.0 clients and servers, or third-party IIOP-based application servers that support the CSIv2 standard, then you should select just CSI as your active secure association protocol.

You can then configure the specifics for either protocol under the Authentication Protocol tasks:

For the IBM authentication protocol, you have control over the SSL settings to be used for inbound and outbound connections – that is, connections from another client to a WebSphere application server (an inbound connection), and from WebSphere application servers to other servers (outbound connection).

For the CSI authentication protocol, you have control over the inbound and outbound authentication settings, and the inbound and outbound transport (SSL) settings. For inbound authentication, you have control over whether basic authentication (user ID and password), client certificate, and trust associations are allowed or required to the server. In addition, if you specify that trust associations be allowed then you can specify which servers are trusted to assert principal identities:

For outbound authentication, you have control over whether the application server can perform basic-auth or client-certificate based authentication to downstream servers, and whether to propagate identity assertions:

In addition, you can specify whether SSL is required for inbound and outbound connections, and the SSL properties that should be used if SSL is used to connect to the server:

JMS Clients

For JMS clients – both suppliers and consumers of JMS messages – the protection mechanism is relatively simple. The JMS specification itself does not describe a standard security model. WebSphere uses anonymous SSL to protect JMS communication, and then performs a simple topic-based authorization check at each end of the exchange. The identity of the supplier of the message may be transmitted in the JMS message header (derived from the credentials of the requesting principal), but this cannot be used to authenticate the sending principal – the identity by itself is not enough to ensure that was who actually sent the message.

Web Services Clients

For web services clients, the authentication requirements are defined in the WSDL for the web service and established through the same web application controls used for traditional web applications from a web browser, the basic JMS security controls, or the application server-level configuration controls for EJB J2EE or CORBA clients, depending on the actual protocol used for the web service.

User Registry

WebSphere supports multiple user registry mechanisms:

• Local Operating System (LocalOS)

• Lightweight Directory Access Protocol (LDAP)

• Custom Registry

You can select the registry you want to use in your network through the user registry configuration setting in the Global Security options in the security center:

LocalOS User Registry

The LocalOS registry is whatever registry is native to the operating system on which WebSphere is hosted. If this is a single server instance or your entire WebSphere network is hosted on a single computer, then the LocalOS registry is the one associated with that computer. If you are running WebSphere on multiple computers in a cluster or as a multi-tiered topology, the LocalOS registry is the one on the computer on which the security server is hosted – either the local node agent or the cell manager.

If you are running on a Unix platform, WebSphere will authenticate against etc/passwd. If you are running on Windows, WebSphere will authenticate against the localhost or against a Windows domain server, depending on how you have Windows configured. WebSphere will authenticate against the Security Access Facility (SAF – and the underlying SAF provider such as RACF or ACF2) on z/OS.

LocalOS-based authentication has the advantage of reusing your platform's user registry and can thus avoid the necessity to create a new user registry. However, it has the disadvantage that in many cases credentials formed on one host will not be recognized by other hosts in the distributed system, and sometimes not even in other processes on the same host. Thus, if you have a distributed network that spans multiple hosts and your application will be involved in requests that propagate between application servers then LocalOS authentication may not work for you – you will be forced to switch credentials between each server. Each server will have to authenticate itself to the down-stream server to initiate any requests to components hosted on that server.

Client-certificates cannot be used with LocalOS authentication to authenticate end users.

You will have to configure a user ID and password of a principal in your local operating system that has the authority to perform authentication verification when using a LocalOS user registry:

LDAP User Registry

The LDAP registry can be one of several LDAP directories supported by WebSphere, including:

• IBM Directory Server version 4.1

• Sun ONE Directory Server version 5.0

• Lotus Domino Enterprise Server R5.08

• SecureWay Directory Server R3.21 and later

• Windows 2000 Active Directory

You select which directory you want to use, and configure how WebSphere controls it through the LDAP user registry settings in the Security Center:

Typically, these LDAP directory servers each have their own schema for how user information in the registry is structured. In addition, you may have extended the native schema for your directory. WebSphere allows you to customize the schema mapping for your directory by specifying where within your schema it should obtain various information it needs to authenticate the user and to derive privilege attributes. These are controlled through the Advanced LDAP Settings in the Security Center:

Custom Registry

In some situations, you may have your own user registry that you use in your enterprise. WebSphere does not require that you convert your entire user base over to the operating system registry or even an LDAP directory. If you want to continue to use your existing registry system, you can introduce your own Custom Registry adapter. You do this by creating an implementation of the com.ibm.websphere.security.UserRegistry interface:

package com.ibm.websphere.security; import java.util.*; import java.rmi.*; import java.rmi.Remote; import java.security.cert.X509Certificate; import com.ibm.WebSphereSecurity.*; public interface UserRegistry extends java.rmi.Remote {  public void initialize(java.util.Properties props)    throws CustomRegistryException, RemoteException;  public String checkPassword(String user ID, String password)    throws PasswordCheckFailedException, CustomRegistryException,           RemoteException;  public String mapCertificate(X509Certificate[] cert)    throws CertificateMapNotSupportedException,             CertificateMapFailedException, CustomRegistryException,            RemoteException;  public String getRealm()    throws CustomRegistryException, RemoteException;  public List getUsers(String pattern, int limit)    throws CustomRegistryException, RemoteException;  public List getUsersForGroup(String groupName, int limit)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public String getUserDisplayName(String userName)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public String getUniqueUser ID(String userName)    throws EntryNotFoundException, CustomRegistryExceptionRemoteException;  public String getUserSecurityName(String uniqueUser ID)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public boolean isValidUser(String userName)    throws CustomRegistryException, RemoteException;  public List getGroups(String pattern, int limit)    throws CustomRegistryException, RemoteException;  public List getGroupsForUser(String userName, int limit)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public String getGroupDisplayName(String groupName)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public String getUniqueGroupId(String groupName)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public List getUniqueGroupIds(String uniqueUser ID)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public String getGroupSecurityName(String uniqueGroupId)    throws EntryNotFoundException, CustomRegistryException, RemoteException;  public boolean isValidGroup(String groupName)    throws CustomRegistryException, RemoteException;  public Credential createCredential(String userName)    throws CustomRegistryException, EntryNotFoundException,           CreateCredentialNotSupportedException, RemoteException; }

then registering that implementation with WebSphere through the admin console:

The Server User ID and Server User Password should be a valid user ID and password in your configured registry. WebSphere will validate this user ID and password when you enable the custom registry setting on the Global Security settings page. If the user ID and password are not valid, WebSphere will not let you configure your registry. Further, these values will be used to validate your authority to bind to that registry every time the application server is started. These checks both ensure your authority to bind to the registry, and to a large extent ensure the correctness of your registry implementation – for example, testing whether the registry's data system can be accessed.

If you build the custom registry implementation using WSAD, you should include the sas.jar and wssec.jar libraries in your build path.

It is your responsibility to make sure the JAR file containing your registry implementation is distributed onto the WebSphere host on which the security server resides, and that your implementation is available to WebSphere's system classpath. It is easy to place your registry JAR file in the lib directory of the application server install root, or you can put the individual classes in a sub-directory of the classes directory of the application server install root. If you put classes in the classes directory, you should create the appropriate sub-directory structure to represent the package path of your class.

Authentication Mechanisms and Controls

Challenging the user for their authentication information is actually only part of the authentication process. The actual authentication of the user occurs by confirming the authentication information the user supplies. The simplest case to understand is with user ID and password authentication. In this model, the user ID is used to identify the user, and the password is used to confirm the user. The idea is that passwords are secret – only a single end user should know their password, and the password should be sophisticated enough that no one else could guess it. Thus, when you log in only you should be able to state both your user ID and your password. If you know both, then you must be who you claim to be.

To accomplish this, of course, the system needs to also know your user ID and password. This is kept in a user registry. Protecting the user registry then becomes as important to safe-guarding the system as it is for everyone to protect their own password – stealing the passwords in the user registry would allow someone to claim to be anyone in the registry and consequently would allow them access to any of the resources or information the user whose password they stole is able to access.

Once the user is authenticated, a token is created that represents that user's authenticity. The token is cryptographically formatted so that any part of the system that needs to know if the user is authentic can examine the token without re-authenticating the user each time. This too needs to be protected for as long as the token exists and is valid, it can be used to represent the user and used to access the resources to which that user has access rights.

Different user registries and different credential tokens have different levels of strength and scope. For that reason, WebSphere offers different authentication options so that you can select the set of capabilities that best meet your needs. These include:

• Simple WebSphere Authentication Mechanism (SWAM)

• Lightweight Third-Party Authentication (LTPA)

Simple WebSphere Authentication Mechanism

Simple WebSphere Authentication Mechanism (SWAM) authentication will authenticate the user's user ID and password against the selected registry and form a credential that is optimized for local use. Credential tokens formed by SWAM cannot be propagated between application servers. SWAM is particularly useful if you are operating a single application server instance in standalone mode. In this case the security server will operate within the application server and the credential tokens generally do not need to be delegated to other application servers.

Lightweight Third-Party Authentication

Lightweight Third-Party Authentication (LTPA) authentication uses the user registry to authenticate the user and then forms a delegatable credential token. The WebSphere Security Server – which may be hosted in the local application server, the node agent, and/or the cell manager, depending on your topology – acts as a trusted third party to the authentication process.

The benefit of using LTPA is that you can share the same LDAP directory among all of your WebSphere hosts, and consequently pass LTPA credential tokens between application servers to represent the authenticity of the requesting principal. Thus, a user can be authenticated and invoke a component, which in turn invokes a component on another server. The down-stream component will be executed under the authenticity and authority of the user.

LTPA credential tokens are cryptographically formatted by a mutually trusted security server built into WebSphere and in this way are quite secure. However, LTPA credential tokens are not formed with service keys and therefore are not confined to being used with specific application servers. Consequently, LTPA tokens are vulnerable to siphoning attacks and should only be used in environments where you can be confident of what software is running on your systems.

LTPA does support authenticating principals with client certificates.

Authorization and Controls

Once the authenticity of the end user can be established, that user's credentials can be used to determine if they should be allowed access to the resource they are trying to invoke. The authorization system is built on the roles-base authorization model defined by J2EE as described further in the Protecting J2EE resources section.

The Topology of the Security System

The classic web application topology consists of any number of browsers, attached through the Internet, via a proxy server, to a web server and on to an enterprise application. The enterprise application is typically connected to a data system. Firewalls will typically isolate the proxy server, creating a demilitarized zone (DMZ) providing a high degree of protection to your company's internal business network:

The authorization server is integrated into the WebSphere application server runtime. However, third-party security providers can substitute their own authorization repositories that will generally run in a separate process under their own control. For example, the Tivoli Access Manager can be used with WebSphere and runs as its own process. The authentication server (referred to previously as the WebSphere security server) is built into the application server runtime, and will either be hosted in the application server, in the node agent, or the cell manager depending on your topology. WebSphere determines the location of the authentication server automatically. The Identity Manager represents whatever principal identity management tools come with your selected user registry – with your LDAP server, local Operating System, or custom registry.

Certificates and Transport-Level Protection

HTTP is the dominant protocol through the Internet. For sensitive content, secure-HTTP should be used – HTTP running over a Secure Socket Layer (SSL), or the more standard Transport Layer Security (TLS). Even if you don't use SSL/TLS with a client-certificate to authenticate the end user, you still need to configure the client and server key-rings to work properly. The key-ring represents the certificate-database associated with your client or server. Nearly all mainstream browsers come pre-configured with the root certificates for most of the major commercial certificate authorities, maintained in their embedded key-rings. However, you must have the public root certificate for your servers configured in the browser to establish your willingness to trust the server – sometimes referred to as establishing trust in the target. If you don't have the root certificate then you will have to acquire this and configure it to your browser before you can communicate securely with your servers.

This same principle also applies for communication between servers. For each server that will be a client to another server, the client-server must be configured with the root certificate of the target server. Server certificates are maintained in a key database associated with each server.

The protection of your network relies on the correctness and currency of your server certificates and their corresponding private keys. Protecting these private keys is essential. WebSphere provides a utility, ikeyman, for creating certificate/private-key pairs, and importing them to the key ring after your preferred certificate authority has signed them. You may consider forming your own in-house public-key administration capability. However this can be a time- and labor-intensive function, especially if you will be using client-certificate based authentication where you need to create, distribute, and maintain client-certificates and their corresponding key-pairs for each user in your system. You should also consider any of a number of commercial signing authority services.

To create a certificate and key pair, start by bringing up the ikeyman utility located in the bin directory under the install root. Create or open your own keyring database, and then switch to the Personal Certificate Requests content section:

Select New to create a new certificate request, and fill in the certificate information.

Notice that the request will be placed in an .arm request file. This is a temporary file – it will only be used to prepare your requests to send to a certificate authority. Change the name of this file if you want to separate it from other pending requests.

You then need to send your request to your certificate authority (CA) to be signed. How you do this will be specific to your CA's public-key infrastructure – the tools and facilities that they use to manage certificate requests. Later, when you get your certification request back you can import the signed certificate back into your key ring. Start by switching to the Personal Certificates content section:

Then press Receive and point to the signed certificate file that you got back from your CA:

This will then store the signed certificate in your keyring.

The CORBA Internet Inter-ORB Protocol (IIOP) is generally used to communicate to EJBs hosted in the EJB container. WebSphere version 5.0 introduces support for the CSIv2 protocol for securing IIOP communication. CSIv2, in turn is layered on the SSL/TLS protocol for establishing trust in the target server. Again, the integrity of this communication depends on the correctness and currency of the certificates in the server's keyring.

Connection to your data system should also be protected. Different data systems offer different mechanisms and protocols for connecting, each of these having varying degrees of protection. Most data systems require that you supply a user ID and password for the connection. You can identify the user ID and password for your data sources and resource adapters in the configuration for those resources in the WebSphere admin console. These are specified under an authentication alias associated with the data source or resource adapter:

Configuring your DMZ

There are two schools of thought about how to configure your DMZ. Putting your web server in the DMZ allows you to serve static content without the overhead and latency that might come from traversing the intranet firewall. Obviously, if your static content contains sensitive information then you should think twice about hosting it in the DMZ. However, the vast majority of static content is relatively benign. On the other hand, managing the content can be more difficult as it requires traversing the intranet firewall from your content publishing systems.

We tend to prefer to place a proxy server in the DMZ and keep the web server in the intranet. Doing so reduces the problems with content management, and makes it simpler to guard against viruses if someone hacks into the DMZ. As a result, you will have a better chance of surviving a Denial of Service (DoS) attack by compartmentalizing your exposures. This can be further enhanced by combining the proxy server with a network dispatcher (also referred to as an IP sprayer) and multiple proxy servers in the DMZ for bandwidth management and workload-balancing the inbound traffic.

The network dispatcher takes in-bound IP packets and routes them across a number of intermediates (usually proxy-servers). In this way, it is able to distribute the in-bound workload across a number of proxy-servers, and by extension across a number of web servers and or application servers behind the intermediate proxy servers. The network dispatcher is usually smart enough to route requests from the same client back to the same intermediate (and backend) to maintain affinity to the state that has been established for that client in the backend servers.

WebSphere ships both a network dispatcher (Web Traffic Express) and a Caching Proxy Server. The Caching Proxy Server will manage a cache of your content – which can overcome the additional latency imposed by hosting the web server in the intranet.

In either case, whether you prefer to configure your web server or a proxy server in the DMZ, you should also enable Network Address Translation (NAT) in your firewall, and configure different port values for the communication through the Internet firewall and the intranet firewall. For example, when you position a proxy server in the DMZ, if you use the standard port 80 for communication from the Internet to your proxy server, then you should configure the proxy server and the web server to communicate on some other port. Doing so deters traffic that may attempt to route around the proxy server in the DMZ.

Network Authentication

Authenticating the user in the proxy server has several advantages. If your site contains particularly sensitive material you can prevent any traffic from entering your intranet that isn't associated with an authenticated user. If your site has several web servers you can enable sign-on in the proxy – authenticating the user to form a login context in the proxy server that can then be propagated to each of the web servers collected at your site, and you can enforce authorization policies on selected URIs – selectively preventing access into your intranet against protected resources.

The proxy server provided with WebSphere provides all of these functions when used in conjunction with Tivoli's Access Manager for authorization enforcement. The credential token created in the WebSphere Caching Proxy will be propagated through the web server to the WebSphere Application Server.

Credential Propagation and Resource Protection

Even if you don't use a proxy server in your network, WebSphere will ensure that a security context representing the authenticated principal is formed whenever a user accesses a protected resource managed by WebSphere. A credential token is formed representing that principal and associated with any work initiated by that principal in the application server. The credential token is propagated to downstream servers – being validated upon entry to any downstream server to ensure that the credential properly represents the authenticity of the principal that it identifies.

For each protected resource touched by work initiated by that principal, the WebSphere runtime will ensure that the principal is authorized to use that resource in the manner requested. For example, if a principal addresses a URL on their browser that results in invoking a get operation on a servlet, the authorization policies governing the security constraints associated with that servlet are checked to ensure that principal has authority to perform that get operation. Likewise, if that servlet is encoded to invoke an Account EJB with, say, a getBalance() operation the runtime will verify that the principal is authorized to access that operation on Account objects. The specifics of access control are discussed further in Protecting J2EE Resources section.

Protecting the Execution Environment

The integrity of your runtime is fundamentally dependent on the integrity of the execution environment in which it is hosted, this includes the computing system; operating system, file system, and the network system; in essence everything about the physical and logical environment that defines the context for the application server. It is important that you establish a strong set of security policies for your web site, and further that you execute and enforce those policies.

The integrity of the WebSphere hosting environment depends, in particular, on you protecting access to the files and directories containing the WebSphere runtime JARs and configuration files, and your application JARs. You should set the ACLs on these directories so that only a small set of authorized administrators are allowed access to those directories. We suggest that you create a special operating system identity representing the WebSphere runtime, starting WebSphere servers under that identity – of course you'll have to give that WebSphere identity access to its own directories and configuration files.

You can establish the identity under which WebSphere application servers will execute from the Process Execution attributes of the application server definition in the admin console:

Secure Associations Between Distributed Components

Authenticating the user is about establishing trust in the user – determining whether they are who they claim to be. That is actually only part of the story. Once a user has been authenticated they would prefer not to have to do it again, repeatedly. Somehow their authenticity needs to be conveyed among all the components that care about the user's authenticity – essentially, any component of the system that will be involved in validating that user's authorization to access a resource, that needs to represent the user, or that otherwise needs access to information about the user.

WebSphere conveys the user's authenticity by forming a credential token at the time the principal is authenticated. The credential is cryptographically computed to ensure that a rogue application cannot construct such a token to falsely represent a user on its own. Moreover, once the token is created, WebSphere can pass the token around, examine it, and in doing so determine that the token continues to represent the authenticity of the principal that it identifies. Consider the following scenario:

A customer logs in to the Plant Store from home. This is an existing customer with an account with the store and is thus entitled to view the store's inventory of rare and exotic plants. They are interested in buying a Night Bloomer, but want to know that the plant was spliced by a local botanist who is known for raising top rated plants. After confirming the plant's history, the customer puts a hold on the plant so that they can come down and check that the plant is in good shape. The store will check the customer's account to ensure they will be able to pay for the plant before putting it on hold for them.

In this scenario all of the objects presented are protected objects – that is, authenticated users can only access them with the authority for such access.

The WebSphere runtime will ensure the customer is authenticated as soon as they attempt to make a Request (1) to a protected object. If they weren't authenticated by an in-network proxy sever, then the WebSphere application server will initiate a Challenge (2) to authenticate the user – by the Login form (3) included with the plant store application. Then, the login information is Authenticated (4) with the Authentication Server and a credential token representing that user will be associated (5) with the thread of work for that customer:

The customer looks into the plant catalog, and finding the Night Bloomer checks its history. This results in an operation being invoked on the Night Bloomer object in EJB Server 1. The WebSphere runtime will Propagate (6) the customer's credential to Server 1. Upon arrival, the WebSphere runtime in Server 1 will Validate (7) the credential to ensure it is valid, and establish that customer's credential in the server associated with the work initiated for that customer. This continues on downstream as the rest of the work cascades across other servers.

The process of propagating and validating the user's credentials in downstream servers is referred to as establishing a secure association for that principal. To make the processing more efficient, WebSphere will maintain a secure session between the application servers on that user's behalf – until the user's involvement in the site is completed. As such, secure associations are stateful.

Identity Assertions

As you might expect, all of the validation that goes into forming a secure association can generate a certain measurable level of overhead in the processing of the credential propagation. WebSphere offers an alternate mechanism to establish associations between servers for the requesting principals – that is, identity assertions. This is also referred to as establishing a trust association for reasons that will become apparent as we describe it:

As before, the customer is challenged and authenticated, and a credential is formed representing the principal (1-5). However, when work is initiated on the downstream servers, the identity of the principal is extracted from the credential and propagated to the downstream server. Some time before this point the Web Application Server will have authenticated itself to Server 1, and so forth – each pair of servers will have authenticated with each other and have formed a secure association between them representing their own authenticity. Based on this secure association, and based on trust policies that can be set for the servers, Server 1 will accept an identity assertion initiated by the Web Application Server. That is, Server 1 will accept that the identity that the Web Application Server provides is authentic merely by virtue of the Server 1's trust in the Web Application Server.

An identity assertion is not as secure as a credential propagation. The identity token in the downstream servers cannot be independently verified to represent the authenticity of the principal it identifies. It is theoretically possible for a rogue application to manufacture an identity token and claim the represented identity is authentic. However, if you can trust your servers – more specifically if you can trust the applications deployed to your servers, then the identity assertion model is more efficient than establishing secure associations between servers.

Delegation

Credential propagation as we describe it above is also a form of delegation – that is, the credentials used for accessing the plant inventory are then delegated on the downstream request for history information.

Arguably the history for the plants at the Plant Store is not all that sensitive – or, at least, it may not have to be protected on a per user basis. Either by knowing that users have to satisfy the authorization policy of the plant inventory and that customers can only get access to the history if they've been authorized access to a plant, or just because you're not all that concerned about who has access to the history information it may not be necessary to delegate the client principal's identity on through to the downstream object.

You can assign each application server instance its own identity – each server is authenticated to the WebSphere security system and a credential token is formed representing that application server's principal. This is referred to as the system principal. In your application you can, for each method or for each component, specify a RunAs deployment descriptor. You can set this descriptor to pass through the client's credential, the server's system credential, or some other specific credential that has been granted a particular role. This deployment descriptor can be set in the WebSphere Application Assembly Tool or WSAD:

By setting the deployment descriptor to use the server's system credential, all downstream requests within that method will be invoked under the server's identity and any authority granted to the server's principal. On the one hand, this means that the server had better be granted the authority that it needs for downstream resources. On the other hand, this is one way of limiting access to downstream resources except through the component method that has been granted that access. In effect, it can be used to make the calling method a privileged operation. See more about privileged code in the next section.

If you are going to run as a specified identity:

then you must map the specified role to a specific user during deployment, defining their user ID and password for authentication purposes in the application:

On occasion, you may find that you want to achieve this for only a subset of the downstream calls that you make within a particular method implementation. Let's say, for example, that you were going to access the Customer Account from within the NightBloomer object, in addition to accessing the plant's history. In this case you might want to access the history under the identity and authority of the server-principal, but then you need to access the Customer Account object under the identity and authority of the client principal. WebSphere does not provide you a way of doing this through declarative policy, but you can achieve the affect by (counter to all other recommendations) using the Java 2 Security programming interfaces to invoke the Pedigree History within a doAs() block. This was discussed in Java 2 Security.

Privileged Code

The RunAs deployment descriptor, when used to control delegation to the servers with a specified identity, enables a form of privileged execution across components, as we have discussed above. However, often the requirements for privileged execution are more localized.

However, there are times where your application may require more than what these permissions will allow you to do. Resource Adapters, as defined by the Java 2 Connector Architecture are a prime example. It is difficult to write a Resource Adapter without native code or without spawning threads. The Java 2 Connector Architecture specifies a mechanism whereby a Resource Adapter can request additional permissions through the security-permission-spec deployment descriptor:

<!ELEMENT security-permission (description?, security-permission-spec)> <!ELEMENT security-permission-spec (#PCDATA)>

The security-permission-spec deployment descriptor should be formatted using the Security Policy File syntax as described at: http://java.sun.com/products/jdk/1.3/docs/guide/security/PolicyFiles.html#FileSyntax. This descriptor can be defined for your resource adapter in the WebSphere Application Assembly Tool.

Similarly, you may need additional permissions in your application. It is important that you realize that when you request additional permissions in your application, you are enabling it to violate some of the programming model constraints imposed by the application server. You are, in effect, entering into a realm where the application server can no longer ensure the integrity of your application. You should proceed with caution! You are assuming the responsibility for making sure your application does not contradict controls and activities performed on your behalf by the application server.

You can request additional permissions for your application by including a was.policy file in the META-INF directory of your EAR file. WebSphere does not provide any tooling to create the permissions you request for your application; however, you construct and edit this file as you would if you were to create a permission file for the Java 2 Security Manager using the Policytool provided with the JDK shipped with WebSphere.

This file follows the same general syntax defined for the Security Policy File as referenced above. However, generally you will use relative names for your application code. The substitution variable "${Application}" can be used in the codeBase to represent your application EAR. For example:

 grant codeBase "${Application}" {  permission java.net.SocketPermission "ahost:7777", "connect, accept"; }; grant codeBase "servlet1.war" {  permission java.net.SocketPermission "localhost:1024-", "accept,listen"; }; 

WebSphere will then merge any permissions requested in the was.policy file within your application with the standard J2EE permissions. WebSphere cannot grant all permissions in all cases and will generate a warning and/or error message explaining why in those cases that it is not able to honor a permission request.

Again, not to contradict other recommendations, if you have a reason for requesting permissions within your code, you can do so with the Java 2 Security doPrivilege() operation.

Credential Mapping

If you employ multiple security realms or authentication domains in your enterprise then you are likely to run into the problem of having to represent the same principal with different authentication credentials. If you invoke an application at a web site that in turn invokes operations on EJBs or, more likely, transactions in a legacy information system, there is a chance that the work you initiate will span two or more of your security realms. If you want the requesting principal's identity to flow between systems – so that all of the work is initiated (and controlled) under the authority of the requesting principal, then you will have to authenticate that principal to both realms.

A principal may or may not have the same identity in both realms. In any case, the realms will want to establish their own trust in the principal – meaning, they will retain their proof information. Generally, you will want to avoid asking the user to login twice (or more) for the same application work. This is referred to as the credential-mapping problem – you need to map the credentials of the principal in one realm to an authentication credential for that same principal in another realm.

WebSphere does not really have any built-in support to fix this problem – at least not in a general fashion. However, there are several solutions you can employ. The first and easiest is to avoid the problem altogether – that is, consolidate your enterprise onto one security realm. This has many benefits all around, not the least of which is to simplify the administration of your security system, and reduce the potential for administration mistakes that could leave your enterprise exposed. However, this is unrealistic for many companies.

Another approach is to employ identity assertions – trust associations. In a trust association model, the principal is only actually authenticated to one realm. Their identity is mapped to a corresponding identity in the other realm, and then asserted to other realm. You must have a trust relationship between the two realms – specifically, you must trust that the applications and software stack in one realm will not abuse the identity of the principal; they will properly reflect the accurate identity of the requesting principal all the way through to the second realm. This only works really well if you've coordinated the realms so that principals have the same identity in both realms – this reduces ambiguity over how to identify the principal in the other realm.

WebSphere provides some assistance for this approach with built-in support for identity assertions. But it leaves it to you to establish trust between the realms; certifying the correctness of your applications and the software stack to properly pass on and protect principal identities. Moreover, WebSphere relies on you to determine an appropriate mapping of the principal's identity between the two realms – again, this is made easier if you can coordinate the two realms so that principals have the same identity in both realms; so that no identity mapping is needed.

If you can't perform identity assertions between your realms, then you are left with the prospect of having to implement your own credential mapping in your applications. You will have to define a mapping database to store the user ID and password (or whatever authentication information is needed) to the foreign realm for each principal that you want to map. When you're ready to cross into another realm, you will then look up the user ID and password for your principal, and use that to log in the user under the foreign realm. You will want to use a JAAS login module for the foreign realm. Of course, maintaining the mapping database requires additional administrative effort – not to mention the risk of it being compromised since it contains the passwords of, presumably, a number of key principals. Given the number of issues associated with both maintaining and protecting a credential-mapping database we recommend that you consider any of a number of different security infrastructure vendors that specialize in supporting this type of function.

All told, credential mapping poses a number of concerns. If you can't avoid multiple realms in your enterprise, and you don't want to accept the implications of credential mapping, then consider this final option. Rather than mapping the requesting principal through to the other realm, simply authenticate to the foreign realm with a single identity and perform all downstream work with that one identity or some small subset of identities. WebSphere provides support for this in all of its connection factories – JDBC, J2C, JMS, and EJB.

Instance-Based Authorization

Another common scenario is that you want to control access to individual instances of objects in your application. Consider, for example, the case where you only want customers to be able to access their own accounts. Again, WebSphere does not provide any support in this area – you will have to solve this in your own application. The easiest solution is to encode the logic right into object – for example, do a test in the Account object to see if the requesting principal (the customer) is the owner of this account. If not, then exit out of the request. This is awkward for a couple of reasons.

First, you have to include this logic in every method of the object, and remember to include it in any additional methods that you add to the object later – in future versions of the object. Also, the logic has to be right – if you introduce any bug you will have to fix that bug in every method that you copied it to.

To make things worse, often the policy won't be quite that simple. You may want to allow access to the Account object by both the account-owner, and other representative employees of your business – such as tellers, or billing adjusters. Of course, the latter could be made a little simpler through the use of the isCallerInRole operation on the servlet or EJB context. Finally, you lose a lot of design elegance by having to combine infrastructure issues (security integrity) in with you business logic (unless you rationalize that it is your business to protect your business assets).

A preferred approach is to isolate your authorization logic. One design pattern is to simply call out to a special security routine that you share in common across your application (or maybe even across your organization). This still leaves you with the problem of packaging that routine in your application EAR (or in a common library), and then updating your application whenever the protection policies change. Another approach that will give you a bit more isolation between your business logic (application package) and your policies is to use the Business Rules Beans framework described in Chapter 5).