ComponentSpace

Forums



Error Responses, Displaying Authn data, and Low Level API support


Error Responses, Displaying Authn data, and Low Level API support

Author
Message
xr280xr
xr280xr
New Member
New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)

Group: Forum Members
Posts: 5, Visits: 31
I'm evaluating the demo for implementing an IdP (initially serving SP initiated requests). I've been looking at developing my own or using some of the free libraries out there so the simplicity of the High-level API, is awesome, but also leaving me wonder where, how, and if certain pieces are happening. Currently I'm looking at the ASP.NET MVC sample but will probably switch to core ultimately since .NET Framework is now obsolete. But speaking of MVC for now:
  1. It's not clear to me what SAMLIdentityProvider.ReceiveSSO actually does since it does not return anything (other than the parterSP out string). I would assume it must throw exceptions - where are those documented? Also in the case of certain bad requests, for instance if an NameIDPolicy were not understood, the spec says an error response should be returned to the SP. How is that handled from a Controller action method?
  2. How can I get he ProviderName (if any) from the Authn response to display on the login form?
  3. Should I want to use the low-level API, where is it documented? Is there a listing of classes and their members with descriptions or how does one learn it?
Thank you.

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
SAMLIdentityProvider.ReceiveSSO receives and processes the SAML authn request from the SP. This includes performing various security checks including verify the signature if required. SAMLIdentityProvider.ReceiveSSO will throw an exception if any errors are detected. All exception classes are under the ComponentSpace.SAML2.Exceptions namespace. You'll find these documented in our Reference Guide.

https://www.componentspace.com/Forums/9107/Reference-Guide

Our recommendation is to catch any exception, log the details and redirect the user to an error page. Exceptions usually occur if there's some sort of configuration mismatch and wouldn't typically occur in production.

There's a SAMLIdentityProvider.SendSSO overload that sends an error SAML response to the SP. For example:


// NameID Policy is not supported.
SAMLIdentityProvider.SendSSO(
    Response, 
    SAMLIdentifiers.PrimaryStatusCodes.Requester,
    SAMLIdentifiers.SecondaryStatusCodes.InvalidNameIDPolicy);



There's a SAMLIdentityProvider.ReceiveSSO overload that makes available the ProviderName and other information through an SSOOptions object. For example:


SSOOption ssoOptions;
string partnerSP;

SAMLIdentityProvider.ReceiveSSO(Request, out partnerSP, out ssoOptions);

string providerName = ssoOption.ProviderName;



The only documentation we have for the low-level API is through our Reference Guide.

https://www.componentspace.com/Forums/9107/Reference-Guide

We also include example projects demonstrating calling the low-level API. However, we encourage everyone to use the high-level API wherever possible as it's easier to use and we make sure all the various security checks etc are performed.

Regards
ComponentSpace Development
xr280xr
xr280xr
New Member
New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)New Member (10 reputation)

Group: Forum Members
Posts: 5, Visits: 31
ComponentSpace - 6/24/2020
SAMLIdentityProvider.ReceiveSSO receives and processes the SAML authn request from the SP. This includes performing various security checks including verify the signature if required. SAMLIdentityProvider.ReceiveSSO will throw an exception if any errors are detected. All exception classes are under the ComponentSpace.SAML2.Exceptions namespace. You'll find these documented in our Reference Guide.

https://www.componentspace.com/Forums/9107/Reference-Guide

Our recommendation is to catch any exception, log the details and redirect the user to an error page. Exceptions usually occur if there's some sort of configuration mismatch and wouldn't typically occur in production.

There's a SAMLIdentityProvider.SendSSO overload that sends an error SAML response to the SP. For example:


// NameID Policy is not supported.
SAMLIdentityProvider.SendSSO(
    Response, 
    SAMLIdentifiers.PrimaryStatusCodes.Requester,
    SAMLIdentifiers.SecondaryStatusCodes.InvalidNameIDPolicy);



There's a SAMLIdentityProvider.ReceiveSSO overload that makes available the ProviderName and other information through an SSOOptions object. For example:


SSOOption ssoOptions;
string partnerSP;

SAMLIdentityProvider.ReceiveSSO(Request, out partnerSP, out ssoOptions);

string providerName = ssoOption.ProviderName;



The only documentation we have for the low-level API is through our Reference Guide.

https://www.componentspace.com/Forums/9107/Reference-Guide

We also include example projects demonstrating calling the low-level API. However, we encourage everyone to use the high-level API wherever possible as it's easier to use and we make sure all the various security checks etc are performed.

Great, thanks for that info. I'm really liking the library so far, but I want to make sure I understand what my responsibility, as the developer consuming ComponentSpace.SAML2, is to be fully SAML 2.0 compliant. Here is the excerpt of the SAML 2.0 spec (from core) that I am using as an example:

When this element is used, if the content is not understood by or acceptable to the identity provider, then a <Response> message element MUST be returned with an error <Status>, and MAY contain a second-level <StatusCode> of urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy.


It sounds like you are saying that SAMLIdentityProvider.ReceiveSSO will never automatically send back that error response so it would be my responsibility to catch an exception and send that myself using the SAMLIdentityProvider.SendSSO overload you provided? That leaves me wondering what other exception handling must be done to ensure SAML 2 compliance? I haven't seen any exception handling in the example IdP projects. In the reference guide I found that ReceiveSSO may throw SAMLException which has all of these sub-classes, but don't know which ones I need to handle by sending a response back to the SP. Am I off on the wrong track here? I kind of hoped you were going to tell me ReceiveSSO writes directly to the response stream in those cases and I would just need to return an empty result from my controller so the SAML requirements stayed taken care of internally.


ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
There are two schools of thought here. In some implementations, if an error is detected at the identity provider (IdP) site an error status SAML response is returned to the service provider (SP). In other implementations, no SAML response is returned and instead control remains at the IdP site. For example, it might redirect the user to an error page. Both approaches are reasonable,

We don't automatically send an error status SAML response as this then gives you the option either to do so yourself or to keep control at your site.

So, if any exception is thrown, the option is to either send an error status SAML response to the SP or to keep control at the IdP site by redirecting to an error page etc. The choice is yours although in our experience many implementations don't send the error status SAML response and instead redirect to an error page.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 3 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search