[jboss-jira] [JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available

[Yi Chen (JIRA)]

    [ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741005#comment-12741005 ] 

Yi Chen commented on SECURITY-709:
----------------------------------

Hi, Anil

Thanks for looking into this. Here is my reasoning for reporting this:

I believe the fundamental issue is that the authentication did *not* fail – it was not performed, because of a failure in the server.  How the failure is diagnosed, by whom, and with what tools is beside the point.

The description at the W3C’s website of the rfc2616 codes  (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) is:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. 

An inability for JBoss to perform authentication because the LDAP server is down/unreachable/misconfigured is not an authentication problem. Instead, W3C says

10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. 

I’m not wedded to this being a 500 – it could be 503 (service unavailable) or 504 (Gateway Timeout).

The rationale here is that the authentication is being done on behalf of a client who is using what s/he believes to be the correct credentials. A 401, where credentials have been submitted, would suggest the credentials are in error – which leads to two behaviours:

- Clients will stop auto-login attempts (e.g. when returning to a wireless network) because bad credentials aren’t going to get better by resubmitting them.
- Users will be confused and angry because their valid credentials are apparently being submitted, and then denied – which in the absence of any other information suggests the (JBoss) service is non-deterministic (a.k.a. “broken”).

By returning a 500-series code, we do not call into question the quality of the authentication tokens – we indicate to the client and to the end user that we are having difficulty in completing their request:  i.e. the problem is at *this* end of the wire, not *their* end of the wire.

Agreed the administrator needs to fix it – but we shouldn’t be misleading the end user on the way.

Thanks,

Yi
                
> Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available
> ---------------------------------------------------------------------------------------
>
>                 Key: SECURITY-709
>                 URL: https://issues.jboss.org/browse/SECURITY-709
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_v4_0_7
>            Reporter: Yi Chen
>            Assignee: Anil Saldhana
>
> I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method:
> ...
> 	   catch (LoginException e)
> 	   {
> 		   // Don't log anonymous user failures unless trace level logging is on
> 		   if (principal != null && principal.getName() != null || trace)
> 			   log.error("Login failure", e);
> 		   authException = e;
> 	   }
> 	   // Set the security association thread context info exception
> 	   SubjectActions.setContextInfo("org.jboss.security.exception", authException);
> 	   return authenticated;
> }
> So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client.
> Steps to reproduce:
> Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira