Since I’ve spent most of the week trying to deploy our application in WebSphere using basic authentication and JAAS, I thought I’d document my pain here so that nobody ever has to go through this again.
Pandora’s Checkbox
When you want to do anything having to do with security in WebSphere, you need to log into the WAS console and check the “Enabled” box under Global Security. You may or may not want to enforce Java 2 Security. Best leave it off and see if things work.
When you Apply these changes, you’ll probably be taken to the Local OS User Registry page to fill in the User ID and Password. By default, WAS uses the local user system for authentication. So put in your system username and password here. The WAS console helpfully tells you that you should save your settings and restart the server. If you do, you’re fucked. You’ve just clicked Pandora’s checkbox and now WebSphere intends to make everything secure, not just the app you want to install. The WAS console will now require a real login and will try to talk to WAS via SSL. Your apps will now be subject to Java security if you checked the Java 2 Security checkbox, meaning that by default they probably won’t be able to access the classloader or the filesystem. The first thing that fails in such a case is usually log4j. So basically, do yourself a favor and don’t restart the server so hastily.
The first thing you should do is update your SSL cert. IBM has a tool that makes it relatively easy to create a keystore and a self-signed cert. Check out AppServer/bin/ikeyman.bat. You can do this one of two ways — you can open up the keystore that comes installed with the server (AppServer/etc/DummyServerKeyFile.jks) or you can create a new one. If you create a new one, you’ll have to update some settings in the WebSphere admin console. So do yourself a favor and just modify the one that comes with WebSphere. The password is “WebAS”. There are actually four files that you need to look at, the server key file, the server trust file, the client key file, and the client trust file. If you’re not all that into security and you really don’t care about SSL anyway, just make the same changes to all four files and don’t worry about the differences. Start with the ServerKeyFile. You want to create a self-signed cert that your server will use to listen on the secure HTTP port. Don’t want to use SSL? Guess what? WebSphere doesn’t care and will use it anyway. Anyway, make sure that “Personal Certificates” is selected from the popup menu and click on the “New Self-Signed…” button and go through the steps to create the cert. IBM makes this really easy.
Next, extract the public key (certificate) from this private key. Select it and choose “extract certificate”. Save this somewhere. Here’s the deal. When a client receives an SSL cert from a server, it needs to verify that the cert is signed by someone they trust — a “certificate authority”. Your browser (and IBM’s built-in SSL client) have a list of CAs built-in but none of them have signed the cert you just made — it’s self-signed. So you need to add the public portion of the server cert as a CA so that the cert is trusted. Technically, you should only need to import the public key into the client TrustFile, but if you don’t really care about making this stuff secure and just want the damn thing to work, I suggest you import it into all 4 files. Change to “Signer Certificates” and add the key that you just exported. Finally, export the original Personal Certificate as a file.
Now open the next file and import both the public and private certs. Again, this assumes that you don’t really care about SSL and are only configuring it because WebSphere makes you do it. If you do care, you probably want to be a little more careful about which keys you install in which files.
Okay, back to the admin console. Go to “Application Servers” and select your server (probably “server1”). Click on “Administration Services”. Change Preferred connector to “RMIConnector” and apply the change. I’m not sure if this ended up being necessary or not, but I had a hell of a time trying to get the SOAPConnector to work. It kept giving security errors, even after I had SSL configured. You can try it without, but you might lock yourself out of the admin console.
One more thing before you attempt to restart the server. Go to the SSL portion of the admin console and click on DefaultSSLSettings. Under “Cipher Suites”, select all of the items and click Add. The page implies that you don’t need to do this if you set the Security Level above it, but I locked myself out when I neglected to explicitly allow each of these algorithms. I got an error to the effect of the browser not being able to negotiate a compatible encryption algorithm with the server.
Now cross your fingers and stop the server using the stopServer script or the Java-based thingy that comes up after installation. For some reason, I get a login dialog when shutting down the server, but not when starting it up. If you get it, put in your Windows/Unix login. With any luck, the server will successfully exit. Note that I found it better to *not* use the Windows aliases in the start menu to start and stop the server because you don’t get a good look at the output before the window closes.
Okay, start back up and check that you can log back into the admin console. If you can’t, you should seriously consider bailing at this point and reinstalling WebSphere.
Install Your AppNow it’s time to install your app. This is a fairly straight-forward wizard. Accept the defaults for every stage (don’t change anything) until you get to the “Mapping Users to Roles” stage, which has an absurd UI. If your app doesn’t use roles, you can skip this. Otherwise, you can check an “everyone?” box to indicate that all users have that role or the “all authenticated” box to mean that anybody who successfully authenticates has that role. If you want to assign a specific user, check the box to the left of the role and click “Lookup users”. See that tiny “Search” button that looks like it’s disabled? It’s not. It took me way too long to figure out that it’s not disabled, it’s just a poorly-scaled graphic. Click Search and you should see a list of Windows/Unix users under “Available”. Highlight and move the ones you want to grant that role to.
Continue the wizard, save your changes, and start up your app. Congratulations, you’ve done in 20 short steps what Tomcat does out of the box.
