WebSphere Security

WepSphere provides both very powerful and very general mechanisms for ensuring security.  It supports three basic security features:  

Like transactions, security options are defined declaratively, as parameters, during deployment or thereafter as maintenance.  Thus, security is "built in" to the environment, just as WebSphere has built in database access, transactions, and, to a large extent, scaling and load balancing.

But, not without a cost.  When security options are being set-up, the environment is extremely fragile.  A user not experienced in this area will encounter a number of unfamiliar terms and options, and he or she will have numerous opportunities to designate choices that can have profoundly negative consequences on the WebSphere systems, often resulting in components that will not start and/or connect with one another.  In those situations, the only "fix" I have found has often been to uninstall and reinstall WebSphere.  This is an expensive undertaking in terms of time and lost work.  

One specific "gotcha" is that versions of WebSphere prior to 3.5.3 (including the 3.5 version currently being used in this course) come with a server authentication certificate (DummyKeyring)  that is out of date.  If the server user enables security settings with this certificate in place, WebSphere will not reboot (which he or she is instructed to do immediately after enabling security and defining options).  There is a "fix" to this problem;  I have installed the fix and followed directions to include the updated DummyKeyring jar file in appropriate classpaths.

For these reasons, I cannot recommend casual experimentation with WebSphere security -- you can lose your entire server and all of the deployment and configuration settings defined within it.  (But not your servlets, ejbs, etc., if you have followed the "best practices" option of setting up a directory structure outside the WebSphere root for them.)  On the other hand, if you can work with a relatively clean server and have the time, you may find it worthwhile to do so.

The remarks, below,  the process of obtaining a certificate for authentication, setting up SSL capability in the server, and WebSphere's approach to access control.

Certificates

Before discussing the steps in the SSL protocol, a brief description of certificates is provided.  A major component in the protocol is an encrypted certificate issued by some well-known third party that identifies a particular server, client, or other process.  This Certificate Authority (CA) must be well-known since to be effective, the client or server performing authentication must already (and independently) have that authority's own public key.  Thus, if you look within the security settings of a Web browser, you will find a list of recognized CAs, such as VeriSign, Thawte, etc.. 

Obtaining Certificates.  Certificates are digitally encoded packages of information that attempt to identify a particular person and his or her organization as well as to identify the authorizing organization, itself.  Certificates include the following information:

  1. An application for a certificate is associated with a particular person and includes information about that person's organization, country, etc.  

  2. When the certificate is generated by the CA, it includes this information as well the CA's own similar signature.  

  3. It also includes a new public key for the applicant, an expiration date, and Domain Names for both the CA and the applicant.  

  4. All of the preceding is wrapped into a bundle and encoded with the CA's private key; hence, these data can only be decoded in the future by someone who (already) has the CA's public key.  

Such certificates are included as one of several components in the messages that are sent back and forth between server and client during authentication.

Validating Certificates.  Certificates offered by one party (e.g., a server) to another (e.g., a client) are validated by checking them against a particular set of conditions or questions.  

  1. The certificate is decoded using the CA's public key.

  2. For a server authenticating a client, it will use the client's public key to decrypt the client's signature.  

  3. It checks the expiration date against today's date.  

  4. If so, it then decodes the CA's encoded signature within the certificate and checks the data included against already held data for that CA.  

  5. The  Domain Name of the requester is then checked against the actual Domain Name used in the communication.  

  6. If the process is that for a server evaluating a request from a client, it may also check the user information included within the server against a list of known and permitted users for that system, sometimes managed in a separate LDAP server.

If all of this checks out for a server's certificate, the client will conclude that the server is authenticated.  

Secure Sockets (SSL)

The most widely used mechanism for insuring confidentiality between a Web client and server and for providing basic machine-to-machine authentication is the Secure Sockets Layer protocol. (Note:  SSL is being superseded by the open source Transport Layer Protocol (TLS), based on SSL 3.0;  however, since the two are very similar, TLS is often mapped into SSL, and SSL is still widely used, this discussion of basic concepts is useful for a basic understanding of security concepts in Web-based systems. At some point it may be updated to describe TLS, per se, in more detail.)

SSL was originally developed by Netscape to provide these forms of security at an infrastructure level, rather than requiring each application to  provide them individually.  A good introduction to the topic is Sun's  Introduction to SSL tutorial.  A companion discussion is Sun's Introduction to Public-Key Cryptography.  A detailed discussion that includes protocol-level examples and relates HTTPS to SSL/TLS is Jeff Moser's The First Few Milliseconds of an HTTPS Connection.

It is important to keep in mind that SSL is a protocol -- that is, a set of rules that describe a set of interactions between two systems.  As such, it operates on top of TCP/IP but below HTTP, FTP, IMAP, etc.  Thus, these latter protocols, and the applications they support, can use (or not use) SSL transparently, once the secure connection is established.

SSL supports three primary security functions:

  1. authentication of the server process to the client
  2. authentication of the client process to the server (optional)
  3. encryption of messages sent between the two, once a "handshake" is completed

As might be inferred from the above, the SSL protocol is actually comprised of two sub-protocols:  an SSL Handshake protocol and an SSL Record protocol.  

SSL Handshake Protocol

The SSL Handshake protocol is used for authentication and to establish basic parameters for subsequent interaction.  One of the most important of these is the symmetric key that will be used by the SSL Record protocol for message encryption.  This is done since symmetric key encryption is significantly more efficient than asymmetric, public/private key methods.  However, public/private keys are used by the SSL Handshake, itself.

The protocol uses some eight or nine steps:

  1. The client initiates a request for an SSL connection by sending the server the version of SSL it is using, cipher settings, some randomly generated data, and other information needed for communication

  2. The server responds with similar information as well as the server's certificate.

  3. The client authenticates the server, using the server's certificate and the procedure described above.

  4. If the server is requesting client authentication, the client returns its certificate.  It also includes data derived from the handshake so far to create a premaster secret, encodes it with the server's public key (included in the server's certificate), and returns it, as well.

  5. If the server is requesting client authentication, it uses the client's certificate to authenticate it.  It then uses its own private key to decrypt the premaster secret.  Both the client and the server then perform a series of steps to generate a master secret.

  6. Both client and server then generate symmetrical session keys that will be used during the session.

  7. The client sends a message to the server saying all future messages will be encrypted with the session key.  It then sends a separate message that is encoded with the session key.

  8. The server sends a similar pair of messages to the client.

  9. The SSL Handshake is complete at this point.

SSL Record Protocol

The SSL Record protocol simply defines the format of records that include the encoded data in the body that will be sent back and forth, once the SSL Handshake is complete.  As would be expected, these records include a plaintext "header" portion and an encrypted data or "payload" portion.

Installing SSL in WebSphere

Installing SSL in WebSphere is independent of access control and is done through the Web browser configuration tool.  A detailed explanation is available in the IBM Redbook: WebSphere v3.5 Handbook.  The process assumes that you have obtained a CA certificate that will be used to validate the server to clients.

After launching the configuration tool, there is a relatively simple seven-step process:

  1. Select Basic Settings/Module Sequence and install the ibm_ssl(IBMModuleSSL128.ddl) module.
  2. Select Basic Settings/Advanced Properties to set the secure host port.  Set port to 443.
  3. Select Configuration Structure/Create Scope to set up  IP/DSN  and the server name (likely to be same as DSN value). Also, specify port value (443).
  4. Select Basic Settings/Core Settings to set up the document root for the secure server.  Be sure to designate VirtualHost as the Scope, at top of page.
  5. Select Security/Server Security to designate the keyfile (e.g., D:\MyServers\http_server\ServerCertificates\Serverkey.kdb) and SSL timeout values( 100 and 1000).  Set Enable SSL to "No."
  6. Select Security/Host Authorization to enable SSL.  Be sure Scope is set to VirtualHost.  Designate Enable SSL to "yes."  I suggest setting "Client Authenticatiion" to "None" unless you have installed a certificate in your browser.
  7. Restart the server.  
  8. If you the http server won't start and delivers a 1067 error, remove the ClearModuleList item from the httpd.config file.

Access Control in WebSphere

Access control is independent of SSL although an option is to require SSL connections in order to access certain resources.  Access control is provided declaratively though settings invoked using wizards in the WebSphere Console.  Key concepts to keep in mind are that access is specified, first, for a given Web container resource, such as a servlet or an ejb, and, second, that access is granted or denied to sets of users with respect to particular objects (i.e., EJBs) through access to their respective methods or sets of methods, called method groups. 

The basic strategy involves four sets of steps.  The first involves defining so-called roles with respect to the Web container and the various resources it supports (e.g., jsps, html pages, Struts .do actions).  the second involves identifying, usually in EJB Session projects, the objects/EJB sessions one wishes to control and designating the particular methods on thsoe objects that will be allowed for the various roles.  Third, the two sets of constraints must be bound in the overall J2EE project descriptor.  And, finally, the server must be configured to support the particular mode of access control desired.  An excellent introduction to this process, illustrated by a sample File Registry, is Roland Barthes'  Testing J2EE Security Applications Using a Custom Registry in WebSphere Studio V5.   See also chapter 29 in Enterprise Java Programming with IBM  WebSphere by Kyle Brown, et.al.

  1. Open the Web project's Deployment Descriptor.
  2. Select the Security tab and there select the Security Roles tab.  Add one or more security roles that will correspond to a specific group of users that will be identified in the registry being used to authenticate users and designate their permitted roles.
  3. Select each role, in turn, and then select the Security Constraints tab for each.  Add a Web Resource Collection for each and then for each collection identify the Authorized Roles allowed to access those resources.  The resources are identified by HTTP methods and by URL patterns, such as *.jsp, *.do, or specific pages/actions.
  4. Select the Pages tab from the Deployment Descriptor and select the particular Authorization method.  In the rest of this discussion, a Custom Registry will be used, specified by selecting the Form option..  Other options include using the OS registry, an LDAP server, or certificates.  If a Custom Registry is being used, indicate a login and error pages.
  5. Open the Deployment Descriptor(s) for Session EJB Project(s).
  6. Select the Assembly Descriptor tab.
  7. Add Security Roles, as defined in the Web Descriptor, that apply to the project's EJBs.
  8. Add Method Permissions for each EJB for each role.  Note the distinction between Home and Remote interface methods.  Note, also, the several way to indicate selection through various checkbox options.
  9. Open the Application Descriptor for the "umbrella" J2EE project.
  10. Select the Security tab and Add the Roles, as defined in earlier steps.
  11. For each Role, select users/groups and designate the name of the corresponding Registry Group.
  12. Start the server you intend to use and open its Administrative Console.
  13. Drill down: Security > User Registries > Custom.  Specify a user login and password that is included in the registry and that you can use to re-invoke the console later.  Specify the fully qualified name of your Custom Registry.  (You will, of course, have include it and related files on your server's classpath.)  You may need to add custom properties if your registry uses files to store names of users and groups.
  14. Drill down: Global Security > Active User Registry and select Custom.  You could also select the Enabled property on this page, but you may also wait and select ti off WSAD's Server Descriptor's Security tab.  Don't select Enable Java2 Security.
  15. Rebuild, republish, and start the server.
  16. Test!