Manually Authenticate within Tomcat 7

[Steve Singer]

We have a web application and have been given the dictum by corporate security to secure certain web artifacts (namely Javascript and images) to only authenticated users (ie, a user can open a browser and enter "https://app/js/program.js" and get the code). The solution seems relatively simple, it is to put the Javascript directory into a security constraint and only allow access to users within a role.

The difficulty we are having is how to get users authenticated. Our authentication process is pretty complex (prompts for expired passwords, gives status of pending expiration, allows reset, etc) and so we can't just have Tomcat perform the authorization using basic or a JDBC realm. What we'd like is to be able to do is this:

1. Continue to have our current authentication process work as it currently does
2. If the user is authorized, have out authorization servlet do whatever j_security_check would have done to flag that the user is authenticated and can be allowed into the security constraint.

Any thoughts on how we might be able to do this? Thanks in advance.

[Tim Holloway]

j_security_check is a pseudo-URL that informs Tomcat to invoke the configured Realm's authenticate() method. When a user has made a secured URL request, Tomcat has returned a login form, and the user has submitted that form, that's when this happens. You cannot invoke j_security_check via a direct manual client URL request.

The authenticate() method does 2 things.

1) Validates user credentials, which when j_security_check is in use means j_userid and j_password from the j_security_check form.

2) Constructs and returns a UserPrincipal object which contains whatever information the Realm might consider useful for future requests, The actual implementation of this object can be pretty much anything, but the object does have to implement the UserPrincipal interface.

OR, rejects the whole thing and constructs nothing, if the credentials aren't approved.

It is extremely difficult to secure support request objects such as javascript, images, and CSS because their very nature requires that the client be able to retrieve and understand them. About the best you can do with most systems is ensure that if they're sensitive that they are within the secured zone and that the primary URL that requests them is likewise in that secured zone. If an insecure URL requests a secured image, for example, there's a problem, since the server doesn't care what a URL is returning. If you make a secured URL request and you're not logged in, the server is going to try and initiate the login, sending back the login page if you're using form-based login, and that's not what an IMG HTML tag wants to see coming back.

I do not recommend complex authentication processes. The more bells and whistles you add, the more potential exploits you add. Which is why the container system ONLY allows for one form out and 2 fields (id and password) coming back. And a lot of what you're talking about should be visible ONLY after the user is logged in or you're giving away free information to a potential invader.

My login pages are spartan, indeed. No extraneous menus, no fancy decorations. All the warmth of an East German checkpoint. Or maybe a 21st Century US transportation center, if you prefer. I only get friendly after you've passed authentication.

You can do a lot with the basic Realm control in J2EE. For finer-grained control I would generally augment it with a servlet listener, but the role-based access control is my first line of defense for authenticated users.