Hello,
We use ComponentSpace for SSO. Lately, I see weird behaviors happening on Service Provider Application Side. Kindly, let us know your inputs.
Client Application uses Okta as their IDP
Client Application Send SSO request through their SAML interface after authentication
Service Provider processes SAML request and does the rest. All good EXCEPT following:
Issue: All cookies, which are added in the Response through Service Provider application are not visible in Browser. There is no hint in Chrome for blocked cookies.
Please note - The standard cookies are available, all cookies created by SP Web application are gone !!
Service Provider creates all secured cookies with SAMESite = none to avoid any blocking.
I have also verified Service provider code and checked all cookies are created up to sending response. But somehow Chrome Browser does not show these Application->Cookies
Any inputs on what can cause the blocking of these cookies ?
Thanks in advance.
Please confirm that SameSite=None and Secure are included in the set-cookie header being sent to the browser.
If the cookie is being set but not sent by the browser, the browser developer tools should tell you why this is occurring.
The following article describes how to use the browser developer tools to investigate missing cookies.
https://www.componentspace.com/forums/11875/Troubleshooting-Missing-Cookies
Let us know what you find.
If the cookie is being set but not sent by the browser, the browser developer tools should tell you why this is occurring.
The following article describes how to use the browser developer tools to investigate missing cookies.
https://www.componentspace.com/forums/11875/Troubleshooting-Missing-Cookies
Let us know what you find.
Thanks for the prompt Response on this issue.
I checked the list of cookies and any filtered cookies for SP Page in Chrome. I still do not find all those missing cookies. As there are no user application cookies existing in my target SP Application Page, nothing for me to check on Secure or SameSite column values related to cookie in debugger tool.
Let me explain our process in details :
In Okta I have set up SAML Entry Point --> say https://myloginportal.mycompanydomain.com/account/sampleassertionconsumerservice along with attributes
A wrapper over okta logs in user and sends the Post request which includes above details
1)SP Code gets the call AccountController:sampleassertionconsumerservice( ..) and
Here in MyLoginPortal.Mycompanydomain.com , web.config I have
two Application related cookies are created here as
httpResponseBase.Cookies.Add(new HttpCookie("Cookie1Name", Secure = true, "Cookie1value")
httpResponseBase.Cookies.Add(new HttpCookie("Cookie2Name", Secure = true, "Cookie2value")
Note - I am not setting SameSite in HttpCookie class here. I am using it from web.config setting for the same.
2) On entering the SAML Entry Point method, code verifies SSO through Receive SSO and then,
3) uses attributes and gets redirected to SP Web Portal Page ( https://mywebportal.clientcompanydomain.com/foo/displayServiceRequestDetail)
this is using ASP.NET call --> Redirect(Above webPortalUrl)
Here in MyWebPortal , web.config I have similar settings as mentioned in 1)
I can only check all cookies (including any blocked one if exists) using Debugger Tool for this WebPortal site (as it is the target on destination, I can not check anything on Loginportal site (having SAML
Please note - the issue only happens whenI have different domains used for Login and WebPortal as shown in bold faced
If my WebPortal Url has same domain like the Login portal url, all work good and cookies are appearing..
so using WebPortalUrl like --> https://mywebportal.mycompanydomain.com/foo/displayServiceRequestDetail gets me all cookies set.
I plan to use SameSite attribute = true in HttpCookie class and just debug the LoginPortal to see if it solves my issue.
Just FYI, We have been using ComponentSpace version 4.3 with this issue happening (earlier we had version 2.8 and all used to work fine).
Please let me know if you have any input or suggestions. This issue is kind of a show stopper for us and disrupting daily client operations causing lot of frustrations.
Again, Thank you very much in advance.
Perhaps I’m not following but if the Login and WebPortal are in different domains they won’t be able to share cookies. If they were in the same domain you could specify the domain attribute when setting the cookies so they could be shared across different hosts.
Is the issue with the SAML_SessionId missing or application cookies missing?
Does SAML SSO complete successfully?
It might help for me to understand the issue better if you could capture the network traffic in the browser and send the saved HAR file as an email attachment to support@componentspace.com mentioning your forum post. Please use browser incognito mode to ensure no old session cookies are used.
Is the issue with the SAML_SessionId missing or application cookies missing?
Does SAML SSO complete successfully?
It might help for me to understand the issue better if you could capture the network traffic in the browser and send the saved HAR file as an email attachment to support@componentspace.com mentioning your forum post. Please use browser incognito mode to ensure no old session cookies are used.
Thanks for your prompt response (and sorry for my delayed one !!).
Good Point about cookies not getting shared between two different domains. Yeah that was my mistake.
And to answer your question - Our Application cookies set in login portal are missing after Redirect call. Yes, I agree that the cookies are not shareable in this scenario.
But, Is there any way we can set the SP's Assertion consumer Service Url with value (with change in domain, so that it matches the domain used for Redirect Request for second domain ) ?
I am using Okta and I want to use the Single Signon Url with domain as matching of Url where we redirect after successful SSO.
For example,
Redirect sites values could be https://site1.domain1.com or https://site2.domain2.com
and SP Assertion Service Url (binding) hosted on Single Login Site on IIS having two bindings as
https://loginportal1.domain1.com/account/samleassertionconsumerservice Or
https://loginportal2.domain2.com/account/samlassertionconsuervice
As a Service Provider, We do not want to host different login portals for assertion consumer service and still want to be able to receive SSO from different IDPs (Urls with diff domains) using same Login Portal (with different bindings).
By default, the assertion consumer service URL specified in your saml.config is included in the SAML authn request sent to the IdP.
<ServiceProvider
Name=“<a href=“https://ExampleServiceProvider””>https://ExampleServiceProvider"
Description=“Example Service Provider”
AssertionConsumerServiceUrl=“~/SAML/AssertionConsumerService.aspx”>
Note that you can either specify an absolute URL or use the tilde (~) character to have it resolved to an absolute URL.
Specifying an absolute URL could be used if a single URL is being used with a cluster of servers behind a load balancer.
There’s also the option to ignore any configured AssertionConsumerServiceUrl and instead specify this programmatically. You’ll find there’s a SAMLServiceProvider.InitiateSSO overload that takes an assertionConsumerServiceUrl argument.
Just remember that, for security reasons, many IdPs check the assertion consumer service URL in the SAML authn request against the URLs they have configured. This applies to Okta.
I’m not sure I completely understand your scenario but hopefully the above options will help address your requirements.
If not, please provide some more detail.
<ServiceProvider
Name="https://ExampleServiceProvider"
Description="Example Service Provider"
AssertionConsumerServiceUrl="~/SAML/AssertionConsumerService.aspx">
Note that you can either specify an absolute URL or use the tilde (~) character to have it resolved to an absolute URL.
Specifying an absolute URL could be used if a single URL is being used with a cluster of servers behind a load balancer.
There's also the option to ignore any configured AssertionConsumerServiceUrl and instead specify this programmatically. You'll find there's a SAMLServiceProvider.InitiateSSO overload that takes an assertionConsumerServiceUrl argument.
Just remember that, for security reasons, many IdPs check the assertion consumer service URL in the SAML authn request against the URLs they have configured. This applies to Okta.
I'm not sure I completely understand your scenario but hopefully the above options will help address your requirements.
If not, please provide some more detail.
I am loading SAMLConfiguration with LocalServiceProvider and PartnerIdentityProviders dynamically.
I need to configure Multiple Local Service Providers for a single Identity Provider. Can you see one of your following article help in this regard ?
https://www.componentspace.com/Forums/51/SAML-MultiTenancy-Applications
I will be interested in one example for .NET (using multi tenancy with single IDP and multiple local SPs)
To support dynamic configuration, we recommend implementing the ISAMLConfigurationResolver interface.
If you take a look at the ExampleServiceProvider’s Global.asax, you’ll find an ExampleServiceProviderConfigurationResolver. This example returns hard-coded configuration for demonstration purposes. In a production application, you would read the configuration from a custom database etc.
A SAMLConfiguration can include one LocalServiceProvider configuration and multiple PartnerIdentityProvider configurations.
To support multiple local service providers, you would have one SAMLConfiguration for each service provider.
The methods in ISAMLConfigurationResolver each take a configurationName parameter. This allows your implementation to return the corresponding configuration. So, for example, you would assign a configurationName to each local service provider.
Prior to calling any of the SAML API calls (eg SAMLServiceProvider.InitiateSSO, SAMLServiceProvider.ReceiveSSO), you specify which configuration should be used by setting the SAMLController.ConfigurationName property.
The Configuration Guide in the documentation folder has more information. This guide is also available at:
https://www.componentspace.com/forums/9350/Configuration-Guide
If you take a look at the ExampleServiceProvider's Global.asax, you'll find an ExampleServiceProviderConfigurationResolver. This example returns hard-coded configuration for demonstration purposes. In a production application, you would read the configuration from a custom database etc.
A SAMLConfiguration can include one LocalServiceProvider configuration and multiple PartnerIdentityProvider configurations.
To support multiple local service providers, you would have one SAMLConfiguration for each service provider.
The methods in ISAMLConfigurationResolver each take a configurationName parameter. This allows your implementation to return the corresponding configuration. So, for example, you would assign a configurationName to each local service provider.
Prior to calling any of the SAML API calls (eg SAMLServiceProvider.InitiateSSO, SAMLServiceProvider.ReceiveSSO), you specify which configuration should be used by setting the SAMLController.ConfigurationName property.
The Configuration Guide in the documentation folder has more information. This guide is also available at:
https://www.componentspace.com/forums/9350/Configuration-Guide
Thank you very much. I was able to implement the multi-tenant SSO as per this document using Multiple Service Providers by implementing Resolver class derived from AbstractSAMLConfigurationResolver.This supports different SingleSigon URLs (URL with different domain as site binding) for same login portal code. Thank you for staying in this loop throughout and guiding us. ComponentSpace Rocks !!
-Chandresh Sanghavi
Thanks Chandresh for the update and your kind words!