Finally, I felt as if I was on to something when I discovered the UserPrincipal wasn't being populated in every situation that resulted in an error. But why?

That one took a little while to figure out, but after testing out a number of different potential fixes, I managed to wander right across the path of the root of the problem.

WebSphere authentication and the UserPrincipal Object
There were three URL patterns that were causing the issue: /categories.do, /themeEditor.do, and /user.do. As it turns out, those same three URL patterns were missing from the list of protected resources in the editor role security constraint.

Apparently, if you're not dealing with a protected resource, then WebSphere doesn't feel the need to populate the UserPrincipal object. To fix the problem, all I needed to do was to add these patterns to the list of protected URLs.

To add the URL patterns, I opened up the Deployment Descriptor of the Web project and clicked on the Security tab on the bottom of the screen. Then I used the tabs at the top of the Security panel to navigate to the Security Constraints section shown in Figure G.

FIGURE G

Open the Security Constraints panel of the Web project Deployment Descriptor. Click picture for a larger image.

I clicked on the EditPages Web resources collection to bring it into focus, then clicked on the Edit button to bring up the Web Resources Collection dialog box in Figure H.

FIGURE H

Enter all of the missing URL patterns here. Click picture for a larger image.

Using the Add button, I entered the missing URL patterns, closed and saved the Deployment Descriptor, and restarted the server.

Once the server was back up and running, I logged back in and started clicking around again. Things were definitely starting to come together, but there was still an annoying little glitch.

If I ever went back to the main menu (which wasn't protected for obvious reasons), I lost the UserPrincipal again and had to go through a few hoops to get back to wherever I was. There was a way to do it involving the Register option followed by the Login option, but that definitely wasn't acceptable.

I finally came up with a solution to this issue, but it wasn't quite as easy as just adding a few missing resources.

The solution (yet another hack)
Solving this problem involved creating an entirely new role and associated security constraint. WebSphere provides an extension to the standard users/groups method of role definition that involves either all authenticated users, or all users, authenticated or not.

By creating a new role that I called everyone, and a new security constraint that allowed both editors, and everyone else, access to the main menu, I essentially secured the resource (maintaining the existence of the UserPrincipal), while still allowing non-authenticated users to get to that main page.