IBM WebSphere Application Server V6.1 has some exciting changes in the area of security. In this brief article we will highlight the key changes and discuss their implications. Rather than just listing features, we will list some problems, complaints, and complexities related to security, and explain how some of the new features in V6.1 make them easier to resolve. Future articles will go into these changes in more detail.
What's new in V6.1?
Let's look at some wishes and gripes we have heard in the past that are nicely addressed in this new version of the product.
"Securing WebSphere Application Server is hard"
As many know, it takes a fair bit of effort to secure a default WebSphere Application Server installation. The basic steps are outlined in WebSphere Application Server V6 advanced security hardening, but this still requires a significant effort.
As part of a major push to simplify the product, many basic security configuration steps in V6.1 are now made by default -- that is to meet the principle of secure by default. Some examples include:
Administrative security is enabled automatically during installation.
All internal transports are authenticated by default.
Most internal transports are encrypted by default. DCS, which normally runs within a cell, remains unencrypted by default, but encryption can be enabled.
The default encryption keys are eliminated. A cell-specific set of keys is created automatically.
JNDI is read-only (rather than read/write) by default to all.
Messaging limits connections to only authenticated users granted the bus connect role by default. AllAuthenticated no longer has that role by default.
With security on by default, many people reading this list might worry that WebSphere Application Server will become harder to manage. We have done a number of things to simplify security management as well. We'll cover those next.
"Certificates, private keys, and encryption keys are too hard to manage"
Another troublesome area is the management of the keys used for encryption and authentication. The management of trust stores and key stores is now handled as a first class construct. This includes managing the certificates and keys in the key stores, as well as managing the replication of those keys, throughout a cell. There are numerous small enhancements that have yielded a vast improvement in usability. Some examples are:
Clients support prompting (like SSH) for adding certificates to the client trust store when contacting a server not previously accessed (this can be disabled if desired).
When configuring an SSL endpoint, the admin client can query the server and automatically import the server's signing certificate (with administrative approval, of course).
The WebServer plug-in configuration will automatically generate a plugin-key.kdb containing a self-signed certificate that is trusted by the WebSphere application servers. This greatly simplifies one of the most difficult SSL configurations.
Ikeyman usage is largely eliminated. Using the admin tools, you can generate certificates, generate certificate requests, import keys and certificates, manage certificates and keys, and even share them across the cell.
Key management applies to more than SSL certificates. The same infrastructure manages the keys used to encrypt LTPA tokens. You can even manage your own custom keys using the console, and applications can access them using IBM-defined APIs. Applications can now be freed from that burden.
There are now programmatic APIs for applications to obtain URLStreamHandlers, SSLContext instances, and SSLSocketFactories, based on the WebSphere Application Server-managed SSL configuration. You can also set SSL properties on the thread to be used for SSL connections that occur on that thread.
Support for custom JSSE trust and key managers enables more control of the SSL handshake.
The ability to associate an SSL configuration with specific target hosts and ports. Previously, a single static SSL configuration had to handle all outbound connections for any given protocol. This enables special configurations for targets that have unique handshake requirements.
Certificate expiration is managed. Where possible, new keys are generated automatically prior to expiration. When this is impossible, notifications are sent via the serious event stream and, optionally, via e-mail. Expiration monitoring is on by default.
LTPA encryption keys are automatically changed at regular intervals. To avoid outages, multiple key versions are simultaneously supported.
Better support is now provided for hardware encryption and hardware key storage.
To learn more, see:
- Securing communications
- Configuring certificate expiration monitoring
- Configuring a hardware cryptographic keystore
"My corporate registry infrastructure is more complicated than just one simple LDAP directory"
Historically, we've required a fairly simple LDAP registry configuration consisting of one LDAP directory. Prior to Version 6.0.2, if it was replicated, we required that the replication be made transparent to the application server (using a load balancer or IP takeover). We could work around these limitations with a custom registry, but now with V6.1 we support much more complicated registry configurations out of the box. This will not solve every problem (for some you will still need a custom registry), but this helps in a great many cases. Here's a quick summary of what's new with the new registry support -- called federated repositories -- in V6.1:
A file registry is supported. For small sites with just a few users (or during early prototypes and development), you can now manage all of your users and groups in a file. There are admin tools for managing these users and the files are automatically replicated throughout the cell.
More than one LDAP directory can be combined together into one logical registry. Now, if your users are spread across multiple directories, you can combine them into one registry for WebSphere Application Server. Just be aware that userids must be unique!
LDAP failover is supported directly. Now, you can list multiple LDAP server replicas by IP address or hostname. The application servers will automatically fail over to backup servers should the primary fail.
Federated repositories are now the preferred and default directory infrastructure, but for compatibility we continue to support the existing LDAP registry, custom user registry, and operating system registry. In the future, we will be enhancing the federated registry component to support even more complicated registry environments.
To learn more, see: Federated repositories.
"I need to isolate my administrators from each other"
Prior to V6.1, administrative authority was cell-wide. If you granted an individual administrative authority, they had it for every node, server, and application in the cell. With V6.1, administrative authority can now be compartmentalized at a finer-grained level. We refer to this as fine grained administrative security.
However, this fine grained authority applies only to wsadmin, so if you need this, you will need to train your administrators to use wsadmin for administration. Fortunately, since we recommend scripting anyway, this just further emphasizes good practice.
To learn more, see: Fine-grained administrative security.
"Configuring the messaging bus to use secure transport is hard"
Readers familiar with the steps in WebSphere Application Server V6 advanced security hardening know that configuring a messaging bus to use secure transport has, in the past, been fairly difficult. Not only did you have to disable the insecure transports, you also had to manually ensure that every client used the secure transports. Now, this is all configured automatically and is easily controllable via the admin console. This is done through a new concept known as permitted chains, which controls what type of transport chains can be used (for example, only those using SSL).
To learn more, see: Transport security in service integration bus.
"I want single-sign on from my Windows desktop to my intranet applications"
WebSphere Application Server V6.1 supports a SPNEGO trust association interceptor (TAI) that allows the Kerberos credential from a Windows desktop to be sent from the browser to the WebSphere Application Server, and then used as the identity for access to WebSphere resources. A slightly different version of the SPNEGO TAI is available from IBM Software Services for WebSphere for previous releases, but with V6.1 we now have a fully supported product solution.
To learn more, see: Single sign-on for HTTP requests using SPNEGO.
"My Web applications mix protected and unprotected URIs, but I still need to know the user’s identity from unprotected URIs"
There are some new Web authentication options that can override the default J2EE authentication behavior. Normally, when requests go to URIs without any authorization constraint, no identity is set up. Applications that mix protected and unprotected URIs can sometimes make life difficult. Sometimes unprotected servlets still need the user's identity information if it is available. With V6.1 this behavior is now supported. You can optionally configure security to persist identity information across requests. Now, if a user accesses a protected URI and then an unprotected URI, their identity will be available. Anonymous users can, of course, directly access unprotected URIs as usual – but you can turn that off as well via another option!
To learn more, see: Web authentication settings.
Feature enhancements from previous releases you might not be aware of
While we have your attention, we want to also mention some great security features that were quietly introduced as part of WebSphere Application Server V6 and later that are still part of V6.1, just in case you missed them.
Generic database identity propagation
One of the challenges of building multi-tier systems is handling end to end authorization and identity flow. One particularly challenging case is with databases. Many databases have strong auditing and authorization built in to protect corporate data. With typical J2EE applications, a single connection pool identity is used for all database access. This undermines the value of the database's native access control and auditing function. In WebSphere Application Server V6, we introduced a feature that makes it possible (with some custom code) to send the originating user's identity information to the database. Now, you can leverage the power of J2EE applications and still use your database's native security functions.
To learn more, see: Database identity propagation in WebSphere Application Server.
Pluggable password storage
WebSphere Application Server stores passwords XOR encoded in the XML configuration files. In general, this is just fine, as a truly stronger solution would require hardware support. That said, if you want to change how passwords are stored (possibly including custom storage of passwords in encrypted form with hardware protected keys), you can do so as of V6.0.2.
To learn more, see: Plug point for custom password encryption.
As mentioned earlier, V6.1 includes support for LDAP failover. Many don't realize that LDAP failover support was actually introduced with V6.0.2.
To learn more, see: Updating LDAP binding information.
We've summarized some exciting new features in WebSphere Application Server security, now available in Version 6.1. This release makes dramatic improvements in the areas of default security, ease of use, and security function. We hope you are as excited as we are, and as anxious to take advantage of these features in your WebSphere Application Server environment.
I would like to thank my colleagues Peter Birk and Alasdair Nottingham for their help in preparing this article.
- WebSphere Application Server V6.1 Information Center
- WebSphere Application Server V6 advanced security hardening, IBM WebSphere Developer Technical Journal, December 2005
- IBM WebSphere: Advanced Deployment and Administration, Roland Barcia, Tom Alcott, Bill Hines, and Keys Botzum, ISBN 0-131468-626
- Advanced authentication in WebSphere Application Server, IBM WebSphere Developer Technical Journal, August 2005
- Database identity propagation in WebSphere Application Server, IBM WebSphere Developer Technical Journal, June 2005