Misleading Access Denied Message

Before a certified user has logged in to PTS (or if their session has timed out), if they try to follow a hyper-link (in a mial) to a case then they get the message 'User not authorized'. This is not helpful and potentially misleading. Ideally the browser should be able to detect the X.509 certificate and auto-login, but failing that the message ought to read "Please log in to perform this action".

-- TobyRodwell - 09 Feb 2006

Developer comments

What is needed to implement this enhacement request is an information from Tomcat that a user requested a given uri, but did not provide a certificate. The only place one can configure "Tomcat SSL behavior" is server.xml file in Connector section. There is a parameter clientAuth that according to Tomcat's documentation can be set to true or false. When set to true, the server will require a certificate for every request on this connector, even to uri's that don't need certificate authentication. When set to false it will require certificate authentication only to those uris that require it. The reason this solution was not implemented yet is a fact that Tomcat handles SSL handshake automatically without notifying web application about a result either for clientAuth=true or for clientAuth=false.

Fortunately there is another mode for clientAuth parameter. This information is not included in Tomcat's documentation and thus was not known when developing the first release. One can set clientAuth=want. It means that Tomcat will ask for certificate for every uri, even those that do not require CLIENT-AUTH. If a client does not provide a certificate and the requested resource requires CLIENT-AUTH then HTTP error response=400 will be returned i.e. BAD REQUEST with "No certificate chain in client's request" message. HTTP error responses can be handled by a web application. For error-code=400 there will be a servlet that will check the error message to find out whether the error was because of certificates. If true, the request will be forwarded to the uri that can perform the operation, but does not require certificates.

Unfortunately this solution implies two sets of uris: one for certificates and the other for other types of authorization. To overcome the problem of different uris for end-customers and certified users the servlet that is invoked on error-code=400 must forward the request to the uri that will perform the operation for not certificated users. Forward does not redirect the client to the other address. It can be seen as a "logical redirect", it performs an action for forwarded uri, but does not physically perform redirect to that uri. Of course this still implies two sets of uris, but end-customers can access the uris of certified users and will be forwarded to uris that does not require certificates.

The only thing to be checked is whether Tomcat in clientAuth=want mode will properly work with Apache server

Effort 5 man/days

-- Blazej Pietrzak - 10 Mar 2006