Hi All,
I have been using ComponentSpace with .Net core 2.0 in the past and had no issues. After migrating to .NET core 2.1 application is broken with attached screenshot.Error reported with below version of component space
Later I migrated to latest version of ComponentSpace application broke with compile time errors for below code.
Please refer the attached file with “comiletimeerror” with highlighted error messages.
Help on this will be much appreciated because we have purchased license and now application is not working condition.
Regarding the compile time errors, we made some minor changes to the options to increase the flexibility and for naming consistency.
Instead of a string, the PartnerName is a delegate that returns a string.
The …Url options have been renamed to …Path.
For example:
services.AddAuthentication().AddSaml(options =>
{
options.PartnerName = () => Configuration[“PartnerName”];
options.AssertionConsumerServicePath = Configuration[“AssertionConsumerServicePath”];
options.SingleLogoutServicePath = Configuration[“SingleLogoutServicePath”];
});
Regarding the dependency injection related exception, we recently changed some singletons to transients.
These are documented in our Developer Guide under the Dependency Injection and Third-Party IoC Containers section.
https://www.componentspace.com/Forums/8235/Developer-Guide
Unless you’re specifying different implementations for the interfaces, the standard setup where you call services.AddSaml should work.
If there’s still an issue, please let us know.
Instead of a string, the PartnerName is a delegate that returns a string.
The ...Url options have been renamed to ...Path.
For example:
services.AddAuthentication().AddSaml(options =>
{
options.PartnerName = () => Configuration["PartnerName"];
options.AssertionConsumerServicePath = Configuration["AssertionConsumerServicePath"];
options.SingleLogoutServicePath = Configuration["SingleLogoutServicePath"];
});
Regarding the dependency injection related exception, we recently changed some singletons to transients.
These are documented in our Developer Guide under the Dependency Injection and Third-Party IoC Containers section.
https://www.componentspace.com/Forums/8235/Developer-Guide
Unless you're specifying different implementations for the interfaces, the standard setup where you call services.AddSaml should work.
If there's still an issue, please let us know.
Thanks Team for quick and prompt response compile time errors is gone with above code snippet. Now authentication is completed from IDP but on success of authentication i am facing below error related to Cookie based authentication. Please refer the attached code snippet and error screenshot. Help on this will be much appreciated.
To complete SSO, the SAML authentication handler signs the user in locally using the sign-in scheme specified by SamlAuthenticationOptions.SignInScheme.
The SignInScheme defaults to Identity.External which is part of Microsoft Identity.
You can specify a different sign-in scheme by setting this option.
The SignInScheme defaults to Identity.External which is part of Microsoft Identity.
You can specify a different sign-in scheme by setting this option.
Can I get example of code snippet please?
I haven’t tested this but it should be something like:
services.AddAuthentication().AddSaml(options =>
{
options.PartnerName = () => Configuration[“PartnerName”];
options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
});
Is there a place or document for below issues. Because one or the other error gets popped up after resolving. Now i am getting the below error once i changed the code based on the above comment.
SamlProtocolException: The SAML message InResponseTo _24f130f8-abf9-4307-b3b6-3dab791c8841 doesn't match the expected InResponseTo _4a778c2d-52d1-412c-ab03-e2b19abb3c2f.
The SAML authn request sent to the IdP includes a unique ID.
The SAML response from the IdP includes an InResponseTo field that ties it to the authn request by this same ID.
If an unexpected InResponseto is received we throw a SamlProtocolException.
In this example, a response is pending for _4a778c2d-52d1-412c-ab03-e2b19abb3c2f but the InResponseTo field in the SAML response is _24f130f8-abf9-4307-b3b6-3dab791c8841.
One way that this can occur is if the SP sends multiple SAML authn requests without waiting for the SAML response.
For example, the SP sends an authn request with ID _24f130f8-abf9-4307-b3b6-3dab791c8841 followed by another authn request with an ID of _4a778c2d-52d1-412c-ab03-e2b19abb3c2f.
At the SP the expected InResponseTo is _4a778c2d-52d1-412c-ab03-e2b19abb3c2f.
However, the IdP returns a SAML response for the first authn request so the InResponseTo field is _24f130f8-abf9-4307-b3b6-3dab791c8841.
To avoid this, you shouldn’t initiate SSO when SSO is pending.
You can also disable this check if required through the SAML configuration.
For the partner identity provider, set:
“DisableInResponseToCheck”: true
Is there any way to fix this issue on the Idp side? Like, to initiate a new session when receiving a new request even if there is a pending one.
Just to clarify what was being discussed six years ago, this refers to multiple SAML authn requests pending SAML responses in the same browser session. In most use cases, this doesn’t occur.
However, the SAML library now supports this.
On the service provider side, multiple pending SAML responses are now supported using the InResponseTo field to identify which SAML authn request matches the response.
On the identity provider side, you have the option of using a correlation ID. When there are multiple pending SAML responses, this ensures a SAML response is sent for the SAML authn request identified by the correlation ID.
There’s also the option of clearing the SAML session state at the service provider prior to sending a SAML authn request so there’s only one pending SAML authn request for this browser session.
Similarly, the SAML session state at the identity provider could be cleared prior to receiving a SAML authn request so there’s only one pending SAML response for this browser session.
However, it’s simpler and possibly safer to not clear the SAML session state and just let the functionality described above execute.