With the high level service provider API, is there a way to handle the scenario where an AuthN request was sent to the Identity provider, but the login was canceled (or a different error occured) at the identity provider?
I’m guessing that a SAMLException is thrown, but I don’t see how you can access any contextual information about the original request (relayState, etc) from the SAMLException object.
Thanks!
If a login or some other error occurs at the identity provider it may send back an error SAML response or simply terminate the SSO flow and display some error page at the identity provider. This will be application specific.
If an error SAML response is returned then we throw a SAMLException indicating the cause of the error. However, we don’t include additional information such as relay state etc.
You can implement the ComponentSpace.SAML2.Notifications.ISAMLObserver interface and receive a notification when the SAML response is received.
The ISAMLObserver interface includes:
OnSAMLResponseReceived(string partnerName, XmlElement samlResponse, string relayState)
This will provide you access to the name of the partner who sent the SAML response, the SAML response XML, and the relay state.
This method will be called prior to the SAMLException being thrown.
Alternatively, if you want even more control, you can use the low-level API.
However, generally speaking, if the SAML SSO fails and the identity provider returns an error SAML response your service provider application will either display an error code and perhaps prompt the user to try again. There’s not really any additional information you would require to perform this processing.
We always welcome feedback. If there’s a particular scenario that you feel could be better supported, please provide some more details.
Thanks.
Thanks! We are working on an implementation of the “TV Anywhere” specification which wraps the SAML AuthN request inside of an oAuth request as defined in section 6 of this document:
http://www.cablelabs.com/wp-content/uploads/specdocs/CL-SP-AUTH-APP-I01-120118.pdf
We need to be able to catch the error so we can send back the proper oAuth response to the client. The method you’ve described sounds like it’s exactly what we need.
Thanks again!
Do you have any example code showing and implementation of the ISAMLObserver interface in MVC? I understand how to implement it, but I"m not really where where to implement it.
I’ve figured out where/how to implement the ISAMLObserver. However, It’s not as useful as I had hoped.
The methods that the ISAMLObserver interface defines don’t expose the context, so there is no obvious way to directly associate it with a specific request/response.
The OnSAMLResponseReceived returns the name of the partner identity provider that sent the SAML response, the SAML response itself, and the relay state.
Specifically what context information are you after?
The problem is that without an HttpContext, I can’t definitively tell which observed SAMLResponse should be associated with SAMLException.
For example, let’s say that 2 requests came in at virtually the same time and both resulted in SAMLExceptions, but for different reasons. The observer doesn’t have enough information to associate that request with the error.
I’ve worked around this for now by adding a new observer right before RecieveSSO is called and having it keep a count of the observed SAML responses. If a SAMLException is thrown, and the observed response count is 1, I know I can safely associate it with the SAMLException.
Am I making this harder than it needs to be?
The sending of the authn request and the receiving of the matching SAML response occur in the same browser session. You could store information within the session state to provide additional context. Also, the ISAMLObserver will be called within the same browser session so you could extract whatever information is required and save this in the session state.
Would this work for your scenario?
Could you tell me precisely what context information you would like at the time the SAMLException is thrown?
Thanks.
All I really need are the primary and secondary status messages from the SAML response.
Thanks for the additional information. This seems like a reasonable request. I’ll see that this information is included in the SAMLException. We will probably create a new exception class derived from SAMLException. Please check with us at the end of the week for a progress update. Thanks.