Add ability to return additional SAML failure codes to RP
Won't Fix
Description fields
Basics
Logistics
Basics
Logistics
Description
In working with the Multi-Context Broker project, one of the expected error conditions will be a failure to satisfy the requested authentication context. It would be useful to be able to relay this information to the RP within the SAML Response. Currently, in SSOProfileHandler.java at line 275 (method completeAuthenticationRequest), the logic checks for a PassiveAuthenticationException and then defaults to a simple AuthenticationException.
Inside my login handler I can set an AUTHENTICATION_ERROR_KEY message that says the authn context was not able to be satisfied (StatusCode.NO_AUTHN_CONTEXT_URI), but due to the logic here, that message only gets logged and never relayed to the RP.
Looking at the organization and structure here, the simple solution for the single use case would be to add another exception type and have the method look for that exception type as well. A more complete solution would likely involve storing more detail about the failure type (relating them to the available status code values in the SAML core spec) or an exception for each of the available status codes.
Either way, I don't expect this work to be done for IdP 2.x. I entered the issue just to note it. I will also enter an issue for IdP v3.
In working with the Multi-Context Broker project, one of the expected error conditions will be a failure to satisfy the requested authentication context. It would be useful to be able to relay this information to the RP within the SAML Response. Currently, in SSOProfileHandler.java at line 275 (method completeAuthenticationRequest), the logic checks for a PassiveAuthenticationException and then defaults to a simple AuthenticationException.
Inside my login handler I can set an AUTHENTICATION_ERROR_KEY message that says the authn context was not able to be satisfied (StatusCode.NO_AUTHN_CONTEXT_URI), but due to the logic here, that message only gets logged and never relayed to the RP.
Looking at the organization and structure here, the simple solution for the single use case would be to add another exception type and have the method look for that exception type as well. A more complete solution would likely involve storing more detail about the failure type (relating them to the available status code values in the SAML core spec) or an exception for each of the available status codes.
Either way, I don't expect this work to be done for IdP 2.x. I entered the issue just to note it. I will also enter an issue for IdP v3.