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.  I was successful in getting the system to support SSL, but not the method access provisions.  I'm still working on this.

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, and a free one offered by Microsoft that is referred to in some WebSphere documentation, http://marting.develop.com/certsrv/. 

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. 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 the Netscape Introduction to SSL tutorial.

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 is that access is specified, first, for a given resource, such as a servlet or an ejb.  And, second, that access is granted or denied to sets of users with respect to particular methods or sets of methods, called method groups. 

The process begins with the setting of Global parameters for the entire site.  This includes whether or not client authentication will be required and the mechanism (OS or LDAP) that twill be used to verify individual users.

Next, one can specify alternative security settings for a particular application if those specified for the Global system are not being used.

Third, one can define new method groups if the default ones will not be sued.

Then, one can configure options for particular resources or programs

The final step is defining the particular settings for the (default) method groups.  These groups include Read, Write, Remove, Create, Execute, and Finder methods.  An additional part of this process is identifying the particular users that will be granted permission to access these methods.