HTTP Authentication and Authorization Failure always sending 401 Challenge

HTTP Authentication Failures are always always returning a challenge.

The Challenge and Response RFC does not require that a Server sends a Challenge for Failed Authentication but if it does require that when a server sends a 401 then it must send 1 or more WWW-Authenticate headers with a comma separated list of parameters describing the Authentication Scheme.

I need thee the following from NegotiateSecurityFilter abilities

1. to not challenge on Failed Authentication; especially Basic
2. hide resources when there is not Authorization Header
3. hide resources when there is an Authentication failure
4. specify the order of NTLM and Negotiate for WWW-Authenticate challenges, e.g. Workgroups, Domains and no local credential manager
   1. these are the following orders that required for various deployments,
   2. Basic, NTLM, Negotiate
   3. NTLM, Negotiate, Basic
   4. Basic, Negotiate, NTLM
   5. Negotiate, NTLM, Basic

See this MDN article for HTTP Basic Authentication Challenge and Basic Authentication Failure

RFC7617 obsoletes RFC2617 which is the current implementation of BasicSecurityFilterProvider

IE and Chrome preemptive Authorization Headers Domain / Enterprise Deployments of Negotiate Security Filter

Withe reference RFC7235#section-3.1 and RFC7231#section-6.5.3 a server is not required to return a challenge and the server can choose to hide the existence of a resource by sending a 404 instead of a 403, (IIS and .NET supports this configuration option) and considering that AD configuration for IE and Chrome for Business provide the ability to use Negotiate or NTLM preemptive means that NegotiateSecurityFilter could be configured to hide the existence of a resource.

---

extract from RFC7617 Upon receipt of a request for a URI within the protection space that lacks credentials, the server can reply with a challenge using the 401 (Unauthorized) status code ([RFC7235], Section 3.1) and the WWW-Authenticate header field ([RFC7235], Section 4.1).

   For instance:

      HTTP/1.1 401 Unauthorized
      Date: Mon, 04 Feb 2014 16:50:53 GMT
      WWW-Authenticate: Basic realm="WallyWorld"

I would like to modify NegotiateSecurityFilter or create a new Filter that Extends NegotiateSecurityFilter to Implement the following

1. new init parameter permissiveAuthorization
   1. true which will be the default leaving NegotiateSecurityFilter to continue to work as is current and will set WWW-Authenticate for requests with Authorization Header
   2. false no Challenges are sent to Requests with no Authorization Header
2. new init parameter hideResources - mutually exclusive of permissiveAuthorization - for failed authentication if hideResources = true, return 404 else return 403
3. new init parameter challengeFailedAuthentication

Notes on permissiveAuthorization and hideResources:

during Initialization of NegotiateSecurityFilter if permissiveAuthorization is false and hideResources = fase = throw ConflictingParameterRuntimeException message = 404 response will be returned for Forbidden access because permissiveAuthorization has been disabled permissiveAuthorization = false

Notes on behaviour of NegotiateSecurityFilter with the new parameters and only a BasicSecurityFilterProvider configured

no Authorization header and permissiveAuthorization = false then return 404 no Authorization header and permissiveAuthorization = true then return 403 no Authorization header and permissiveAuthorization = true and hideResources = true then return 403

no Authorization header and permissiveAuthorization = false and hideResources = false then return 404

Notes about allowGuestLogon false hideResources and successful authentication

1. a successful password authentication where allowGuestLogin is false, if hideResources then return a 404 otherwise return 403

https://tools.ietf.org/html/rfc7231#section-6.5.3

A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code (Section 6.5.3 of [RFC7231]).

The Client MAY submit credentials when receiving a WWW-Authenticate and the Client MAY preemptivley submit an Authorization on first request to a resource If failed Authentication then return with 403 or 404 [RFC7231 7231#section-6.5.3)(https://tools.ietf.org/html/rfc7231#section-6.5.3)

6.5.3. 403 Forbidden

   The 403 (Forbidden) status code indicates that the server understood
   the request but refuses to authorize it.  A server that wishes to
   make public why the request has been forbidden can describe that
   reason in the response payload (if any).

   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.  The client
   SHOULD NOT automatically repeat the request with the same
   credentials.  The client MAY repeat the request with new or different
   credentials.  However, a request might be forbidden for reasons
   unrelated to the credentials.

   An origin server that wishes to "hide" the current existence of a
   forbidden target resource MAY instead respond with a status code of
   404 (Not Found).

[dblock]

I think it’s the same debate as disableSSO in #636. Personally I am not opposed to an enabled flag in every filter that avoids having to comment the filter out.

Naming wise, I would change disableSSO to enabled and default that to true and implement the same in this filter (and every other) in some base class that prevents calling doFilter altogether.

[pedroneil]

@dblock thanks for challenging my options and helping me find the cause of my issue; I’ll update the title and the desciption