[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] 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 -- 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