Skip to content

Is transparent access control worth unintelligible error messages?

Partly egged on by Rob and Brian, I just took a long overdue look at container managed security for web applications.

My conclusion: it’s nice, but there is one major flaw that dooms the whole premise. Users expect informative error messages when they ‘sign in’ and there’s no way to do that with container managed security.

I was using Tomcat 4.1, which is to say, I was examining the servlet 2.3 specification. (I just looked at the 2.4 specification and can see no amelioration of the above issue.) I also focused on the FORM method of authentication, as that’s the most customizable. (I imagine, for an intranet app obsessed with security, client certificates would be an worthwhile avenue of investigation.) I found the servlet specs to be very helpful in this process.

With the FORM method of authentication, you can customize the appearance of your login and error pages, to some extent. This is a huge win.

I really liked the automatic access control–no checking at the beginning of every ActionForm or JSP for any specific attribute. Additionally, you can protect different URL patterns easily, and for most of the applications I write, this is enough. If you need to protect buttons on a page, you can always resort to isUserInRole.

Also, you can protect the login and error pages, which should never be accessed directly in a separate /safe directory, to which you can prohibit all access.

For the times when the user is denied access to a resource, you you can create a custom 403 error page, using the error-page directive in web.xml. Unfortunately, you only seem to get three attributes: javax.servlet.error.message, javax.servlet.error.request_uri and javax.servlet.error.status_code, which limits the nature of your response. These were what Tomcat gave me–I don’t think it’s part of the spec. Regardless, IE, with default settings, doesn’t display any custom error messages, which makes this a rather moot point for general webapps.

Creating a logout page is fairly easy, just call session.invalidate() (though there seem to be some non standard methods of doing it as well).

However, as mentioned above, I just don’t think that users will accept the generic login error messages that you are forced to give. For instance, you can’t tell whether a user didn’t enter a password, or entered an incorrect password. You can’t redirect them back to a login page with helpful error messages around the incorrect box. These are fundamental issues with authentication–no serious webapp simply throws up its hands when a user doesn’t login correctly the *first* time.

Separate from user experience, but still related to authentication behavior, you can’t ‘lock out’ users who’ve attempted to login too many times. Sure, you can keep track of how many times they’ve tried to login, but the authentication process is out of your hands.

Additionally, the fact that you’re tied to a particular implementation for user/role definition means that writing custom authentication code that just accesses a RDMBS is actually more portable.

The answer, to the question posed in the title of this post: “is transparent access control worth unintelligible error messages?”, is almost always “no.” And folks accuse developers of not having any sense of user interface!

2 thoughts on “Is transparent access control worth unintelligible error messages?

  1. Kris Thompson says:

    I almost agree with you Dan. Just recently I have been diving into extreme detail into Security using WebWork2 and found that CMS is great for simple sites because it is a quick and simple way to slap on CMS…really quick… and it can just as quickly have role based authorization as you mentioned. But due largely to the issue of generic login screen it just doesn’t seem to integrate that well into the site. Now for a small companies intranet it doesn’t matter. After learning more about webworks’s ability to collect a group of actions into a namespace and tie that into Filters as your security I would say (if using Webwork) that is my preferred method. As a newbie to AOP I would like to investigate it more as an option but comparitivly speaking on the amount of time it would take to set up, CMS still blows it away. I’m not going to discount CMS as an option because cost effectively speaking it is nice.

  2. Kris Thompson says:

    Forgot to mention this, maybe as a quick option one could use this sourceforge project as a better integrated solution, http://securityfilter.sourceforge.net/.

    I have never used it myself but it was recommend to me to consider.

Comments are closed.