Java Enterprise in a Nutshell (In a Nutshell (OReilly))

10.6. Other J2EE Security Topics

In this section, we discuss a few other topics relevant to J2EE security, including securing enterprise resource managers, web service security, and single sign-on.

10.6.1. Accessing Enterprise Resource Managers

An enterprise may have a wide range of enterprise resource managers such as relational database systems and message-oriented middleware products. To establish a connection to these resources, authentication is often required. You can manage the authentication details for these resource managers in one of two ways. You can manage it yourself in your application code, or you can use the application server or container to manage the connection details for you.

Resource manager references are declared in web and EJB deployment descriptors using <resource-ref> elements. Full details on declaring resource references in deployment descriptors can be found in Chapter 2. In terms of the authentication mode to be used with a given resource, this is specified using the <res-auth> element within the <resource-ref> element. To indicate that the container should handle authentication details, set the <res-auth> element to Container. You then need to configure the authentication details for the resource in the container, using its management tools or container-specific configuration files. If you'd prefer to manage the authentication details in your application code, set the <res-auth> value to Application. It's usually preferable to use container-managed authentication since it facilitates the portability of your application across development and production environments. It also reduces the amount of code you need to maintain.

10.6.2. Web Services Security

Chapter 12 provides general details on implementing SOAP-based web services using JAX-RPC and SAAJ. Securing SOAP services is a topic that is still in flux in the market in general. A number of competing standards exist for sending client credentials across a SOAP request, for encrypting SOAP communications, and for managing access to SOAP services. In part because of this uncertainty around web service security protocols, the J2EE 1.4 and JAX-RPC 1.1 specifications do not make any provisions for standardized web service security models.

Here, we simply introduce a few of the current techniques in practical use for securing web services. Future versions of the Java standards around web services, and broader agreement in the industry at large about web service security protocols, will make the job of securing web services much easier than it is today.

One common way to authenticate a web services client is to use BASIC authentication. In this approach, the web service client is responsible for providing authentication credentials through HTTP headers to the web server that fronts the web services being invoked. Of course, this approach works only in SOAP messages exchanged over HTTP, and in order to be truly secure, the underlying communication transport should actually be HTTPS. It is also possible to use CLIENT authentication (i.e., the client provides its credentials in the form of a certificate) with web services. In fact, this form of web-based authentication is more suited for web clients since web clients are often other applications, which means the certificate exchange is between two servers and much easier to manage than end user certificate distribution.

We discussed the concept of digital signatures at the beginning of this chapter. XML documents can also take advantage of this technique, using standards like XML Signature. XML Signature is a joint IETF and W3C standards effort, and, among other things, it provides well-defined schema elements that can be used to attach digital signatures to XML documents, such as SOAP messages. The Java XML Digital Signature API (JSR 105) provides a standard Java API for both producing and consuming XML documents signed using XML Signature.

XML Encryption is a complementary standard, also maintained jointly by the IETF and W3C, that provides a standard approach for encrypting and decrypting the contents of XML documents. A corresponding Java API, the Java XML Digital Encryption API (JSR 106), is currently in development.

From the standpoint of SOAP-based web services, however, both XML Signature and XML Encryption are low-level security protocols. They deal directly with the XML contents of SOAP messages, so for a Java developer to use the corresponding Java APIs in either a SOAP client or service, she would have to delve into the ugly details of the XML data being sent back and forth. In an ideal world, there would be a standard way to integrate these XML security protocols into a SOAP message context and extract the relevant application-level information (the sender's identity, roles, etc.) to drive authorization and personalization features. In the world of general XML and web service protocols, the WS-Security standard (managed by the Organization for the Advancement of Structured Information Standards (OASIS) is a higher-level security protocol for web services. It integrates XML Signature and XML Encryption and specifies details on how these and other security measures are to be applied within SOAP messages. Unfortunately, a standard Java API for interacting with WS-Security-protected SOAP messages, and mapping them into standard Java security entities like Principals, Subjects and Permissions, is still pending. Some open source and commercial implementations of WS-Security, such as the Apache Axis WSSE project, do exist, but broad support for WS-Security in the J2EE environment is still in development.

10.6.3. Single Sign-On (SSO)

An enterprise has a multitude of applications, each requiring security services including, but not limited to, authentication. Single Sign-On (SSO) is a system for authenticating a particular user just once to permit access to all the different applications in an enterprise.

SSO has usability benefits because the user does not have to remember different usernames and passwords for all the different applications. SSO has benefits for the organization as well because the organization provisions an individual just once. When an individual joins the organization, he is given access to the appropriate applications all at once, and when the individual leaves the organization, it discontinues the user's access to all applications. In addition to the convenience features of SSO, organizations can save money; password resets are a frequent request and occur largely because of having to remember a multitude of passwords. Administrative costs can potentially drop when SSO systems are implemented.

SSO is principally concerned with authentication. What about other security features such as authorization? The industry is moving toward a standardization of security information exchange with Security Assertion Markup Language (SAML). SAML supports not only authentication but also authorization. You can even use SAML to create federated identities that integrate different SSO providers. The Liberty Alliance Project is embracing SAML with support for federated identities. JSR 155 provides the standard Java specification as well as a reference implementation for SAML.

What is involved in adopting SSO? The following sections discuss some of the issues related to implementing SSO in the context of J2EE security.

10.6.3.1. SSO products

Many different SSO products are on the market today, including Computer Associates' eTrust Identity and Access Management (which includes Netegrity SiteMinder), Entrust GetAccess, IBM Tivoli Access Manager, Oblix COREid, and RSA ClearTrust. When evaluating the products, be sure to check out their integration with your favorite application server(s) and client desktop applications.

A common temptation is to do point-to-point SSO integration between systems and applications without a clearly defined SSO strategy. The danger with such integration is that the implementation may turn out to be more time-consuming to develop, maintain, test, and deploy. Additionally, such an implementation may potentially be insecure and fragile.

10.6.3.2. Security stores

A single master location for user identities, roles, and permissions, sometimes called a security store, is ideal for implementing SSO. One of the most common security store solutions utilized in enterprises is an LDAP-based service. LDAP is ideally suited to store security information that is read many times and updated few times. Some other common solutions for security stores are custom or product-defined relational database schemas or operating system domains such as Windows Active Directory. Accessing security stores from your J2EE applications can be done using low-level APIs like JNDI or JDBC, or you can integrate the security store behind a JAAS provider. Alternatively, at the highest level, you can integrate the security store directly into your application server, allowing you to use declarative security measures in your deployment descriptors using identities and roles managed by the SSO environment. Your choice of these options will depend on the particular security store and application server(s) in use in your organization.

The ideal SSO situation of a single enterprise-wide security store is relatively rare, sadly. A typical organization will more likely have multiple security stores for various reasons such as legacy, performance issues, license limitations , and organizational and political factors. In these situations, the enterprise needs to keep these stores in sync with a variety of techniques, such as live data links, data replication, batch updates, and others.