HTTP request fails with 401 if more than one IdentityProvider produced no SecurityIdentity but is allowed if a single one is used

[sberyozkin]

Describe the bug

Bill @patriot1burke has spotted that when a matching HttpAuthenticationMechanism requests the request credentials be converted to SecurityIdentity then if only a single IdentityProvider returns null then the request is allowed to continue with an anonymous identity, despite the credentials being available - but will fail with 401 if more than one IdentityProvider has not provided SecurityIdentity

Expected behavior

It has to be consistent in both cases.

And IMHO it has to be 401 because it should be a responsibility of HttpAuthenticationMechanism to decide whether a null SecurityIdentity is returned or not: if it does not recognize the credentials - return null, if it does - then it has to be converted.

Allowing the request to proceed where for example the provided Basic Auth credentials, with the proactive autentication enabled, are represented as an anonymous identity and eventually returning 403 at the RBAC level (as opposed to 401 if the name or password are wrong) is not quite correct.

See also #17192

CC @patriot1burke @stuartwdouglas

[sberyozkin]

@michalvavrik Have a look at this one if it can be of interest please

[michalvavrik]

Will do, thank you.