[Proposal] error page handling on authorization failure

[Jeff Tulley <JT...@novell.com>]

Right now when a resource is secured, after the user enters their
credentials, if the credentials are not authenticated, a user-specified
error page is shown, specified from web.xml.
But, if the authentication happens correctly and the user is not in the
role so the authorization fails, this same error page is NOT displayed,
but rather a 403 error, "Access to the requested resource has been
denied".  At that point, the session already has authenticated
credentials, and it is impossible to hit back and try again.  You either
get "j_security_check is unavailable", or repeat 403 errors, depending
on what you try to do.  Your only recourse is to close the browser and
start a new session.

proposals:
1) If possible, on authorization failure, dump the authenticated user
credentials, as if we never tried to authenticate
2) Redirect to the same error page when there is an authorization
failure but authentication success.

The spec says this:

"SRV.12.5.3 Form Based Authentication
...
When a user attempts to access a protected web resource, the container
checks
the user's authentication. If the user is authenticated and possesses
authority to
access the resource, the requested web resource is activated and a
reference to it is
returned. If the user is not authenticated, all of the following steps
occur:
1. The login form associated with the security constraint is sent to
the client and
the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the username and
password
fields.
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the
information from the
SECURITY
84
form.
5. If authentication fails, the error page is returned using either a
forward or a redirect,
and the status code of the response is set to 401.
6. If authentication succeeds, the authenticated user's principal is
checked to see
if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource
using the stored
URL path.
The error page sent to a user that is not authenticated contains
information
about the failure.
..."


So, it is ambiguous, and does not specify what to do.  It also does not
forbid it.  Also, this error is hard to deal with as is, so I do not
think that we would be breaking backwards compatibility to suddenly
start handling it.  At least, if we are, it would probably be greeted as
a welcome change, not a bad one.

This really should be dealt with in the spec, preferrably with a
separate page for each type of failure, or at least outright specifying
that the one page should be used for both cases.

What do you all think?  It seems like this should be an easy fix, as
well, though I could be wrong.

Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org