The SAML specifications (core, binding, profile) state a SAML responder SHOULD respond with a SAMLResponseType which MUST include a Status element. Essentially the only time a responder may elect not to respond is if a denial of service attack is occurring. Note the SAML status code is independent of the HTTP status which should indicate HTTP success so that the client can consume the response message containing the SAML error status.
During testing we observed in the case of an unsupported NameIDFormat in the AuthnRequest Keycloak displays "WE'RE SORRY ... Unsupported NameIDFormat" on what should have been the login page where credentials are entered. When this occurs NO response is issued to the SAML Requester with a status indicating the failure.
There are several problems with this:
- It violates the SAML protocol
- The flow is broken, the requester does not know what happened and for all it knows the responder died or network connectivity was lost, it may or may not timeout.
- It's confusing the user, the error page they are presented with means nothing to the casual user, most will be utterly dumbfounded by what appears or why.
In the particular case of an invalid NameIDFormat the problem occurs in the file
services/src/main/java/org/keycloak/protocol/saml/SamlService.java on line 314
While I'm not familiar with the internals of Keycloak it would appear the problem lies in the use of "return ErrorPage" rather than generating a SAML response.
Quick code reading suggests there are numerous places where "return ErrorPage" occurs instead of generating a SAML response, all of these should be fixed as well.