ComponentSpace

Forums



How to retrieve Session index from the SAML Assertion


How to retrieve Session index from the SAML Assertion

Author
Message
ravikanth
ravikanth
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Awaiting Activation
Posts: 3, Visits: 18
Hello Component team.

We have implemented the  SAML Service to handle the SAML Authentication using component space, The service handles SP-Initiated flows. I have implemented the SP initiated SSO and it works as expected for SAML IDP's {PingOne,OneLogin}, I'm now working on logout flow, to successfully logout the user from the SAML IDP, the SLO (logout) request should contain the session index and name id.  As part of the SP-Initiated SSO  implementation the ReceiveSsoAsync() method returns the SSO results which contains the property "spSsoResult.UserID" and other properties are saved in database, however I could not find a way to extract the session index present in the SAML ACS, I believe which is must to logout from the SAML IDP's

ACS response value
 <saml:AuthnStatement AuthnInstant="2019-11-25T16:50:41.389Z" SessionIndex="I12squujoEC7-W2HnvBkmDDcLQGfXt2LNEgTqQ_rX5T__PTAQG4w">

FYI**: I'm not sure if we are using ASP.Net Session to save the session information, we are defaulting to componentSpace requirements, if any.  in our case the service does not maintains any state, as it just provides the SAML Services, the service extracts the information from the assertion and save it in database so that other authorization services can use that information and provider the resources to the users.
 
In  article, its stated that component space will take care of providing session index and nameId as part of logout request https://www.componentspace.com/Forums/9032/SAMLServiceProviderSendSLO-question?JumpToFirstUnreadPost=1

We store the NameID in the internal SAML session state. This is what's included in the logout request.
We don't use the FormsAuthentication.SetAuthCookie value etc.        

  Regards
ComponentSpace Development"

Some of the concerns I have around componentSpace handling are
1. SAML Service we have implemented would be running as microservice with multiple instances, all the service request coming to saml service would be load balance, no guarantee that the SP-initiated logout request would come to same SAML Microservice where the log-in happened.
2. In this case how would component space know about the user session, if the request is landing on some other SAML Service instance.
3. In our case ASP-SessionID is used by the other resources provider services, not sure how it would work with multiple ASP-sessionid values.

Appreciate any help!!, Thanks in advance!!

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)

Group: Administrators
Posts: 2.1K, Visits: 5.4K
We maintain SAML session state to support, amongst other things, SAML logout. This session state includes the session index and NameID. When you call InitiateSloAsync, we lookup this state and include the session index and NameID in the logout request sent to the IdP. This isn't information you need to maintain or supply which is why it isn't returned to you by ReceiveSsoAsync.

By default the session state is saved in an in-memory IDistributedCache implementation. The key into the cache is stored in a saml-session cookie.

If you're running in a load balanced environment and you're not using sticky sessions, the session state should be stored in a distributed cache such as Redis or a SQL server database. More information may be found at: https://www.componentspace.com/Forums/8481/Web-Farm-Guide

Also, you need ensure the saml-session cookie is sent by the browser. This should happen automatically but it might be dependent on exactly how your microservice is called.

Regards
ComponentSpace Development
ravikanth
ravikanth
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Awaiting Activation
Posts: 3, Visits: 18
ComponentSpace - 11/25/2019
We maintain SAML session state to support, amongst other things, SAML logout. This session state includes the session index and NameID. When you call InitiateSloAsync, we lookup this state and include the session index and NameID in the logout request sent to the IdP. This isn't information you need to maintain or supply which is why it isn't returned to you by ReceiveSsoAsync.

By default the session state is saved in an in-memory IDistributedCache implementation. The key into the cache is stored in a saml-session cookie.

If you're running in a load balanced environment and you're not using sticky sessions, the session state should be stored in a distributed cache such as Redis or a SQL server database. More information may be found at: https://www.componentspace.com/Forums/8481/Web-Farm-Guide

Also, you need ensure the saml-session cookie is sent by the browser. This should happen automatically but it might be dependent on exactly how your microservice is called.

Thank you very much for the response..

We would be saving the session in the CosmosDB, does component space support CosmosDB?
Does the component space clean-up the session data automatically, or do we have to handle session clean-up?
 I see that the saml-session cookie is getting added as cookie in the Assertion response, I don't see its being set as set-cookie with path, I believe that saml-session cookies is used to retrieve the session information from the cache. Surprisingly I don't see the cookie is saved in the browser for the SAML Service URL(domain), I'm not sure how to set the cookies in the browser. Are there any alternative ways to set the cookie?

acs:
POST https://<test>/saml/acs HTTP/2.0
content-length: 8573
pragma: no-cache
cache-control: no-cache
origin:
upgrade-insecure-requests: 1
content-type: application/x-www-form-urlencoded
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
sec-fetch-site: cross-site
sec-fetch-mode: navigate
referer: <IDP URL>
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,ja;q=0.8,en-IN;q=0.7,en-GB;q=0.6
cookie: saml-session=80e1d058-4fa5-4450-98b9-59f47ea47f86;
Host: <host>

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)

Group: Administrators
Posts: 2.1K, Visits: 5.4K
We support any implementation of the IDistributedCache interface.
I see that Microsoft have an implementation of IDistributedCache using CosmosDB.
https://github.com/Azure/Microsoft.Extensions.Caching.Cosmos

We set expiry date/times on the session data stored in the IDistributedCache. Depending on the implementation, you shouldn't have to do anything specific to clean up. However, you should confirm this is the case with CosmosDB implementation.

The cookie is present in the HTTP Post to your ACS endpoint. This appears to be correct. If there was an issue I'd have to see a trace of the network traffic.

I suggest getting everything working with a single server/instance and using the default in-memory IDistributedCache implementation. Once that's working, switch to the CosmosDB implementation of IDistributedCache to continue your testing and then finally test in a multi-server/instance environment.

Regards
ComponentSpace Development
ravikanth
ravikanth
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Awaiting Activation
Posts: 3, Visits: 18
ComponentSpace - 11/26/2019
We support any implementation of the IDistributedCache interface.
I see that Microsoft have an implementation of IDistributedCache using CosmosDB.
https://github.com/Azure/Microsoft.Extensions.Caching.Cosmos

We set expiry date/times on the session data stored in the IDistributedCache. Depending on the implementation, you shouldn't have to do anything specific to clean up. However, you should confirm this is the case with CosmosDB implementation.

The cookie is present in the HTTP Post to your ACS endpoint. This appears to be correct. If there was an issue I'd have to see a trace of the network traffic.

I suggest getting everything working with a single server/instance and using the default in-memory IDistributedCache implementation. Once that's working, switch to the CosmosDB implementation of IDistributedCache to continue your testing and then finally test in a multi-server/instance environment.

Appreciate your support!!
Thank you very much for your suggestion..
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)ComponentSpace Development (3.1K reputation)

Group: Administrators
Posts: 2.1K, Visits: 5.4K
You're welcome.

Regards
ComponentSpace Development
GO


Similar Topics


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


Password:


Social Logins

Select a Forum....









ComponentSpace Forums


Search