ComponentSpace

Forums



SSO Session Timeout


SSO Session Timeout

Author
Message
Serhii Krut
Serhii Krut
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 13
Hello,
Our client has an enterprise application that uses .Net Core ComponentSpace for SSO. Since Web farm with a load balancer is used there, DistributedSqlServerCache was implemented according to the development guide. 
However, we faced the next timeout issue:
1. User logs in using SSO. During it, three sessions are created: local application (SP) session, IdP session, and ComponentSpace SSO session that is stored in the database.
2. SP session has a sliding expiration timeout, so it is active since the user works in the application. Let's assume IdP has 2 hours session expiration. ComponentSpace SSO session by default has 30 minutes timeout;
3. After an hour of active work user presses "Logout". SP session is terminated, then CanSLO method is called to check if we can do Single Logout. But since by that time ComponentSpace SSO Session is already expired, it returns false and SingleLogout doesn't happen. 
As the result, the IdP session is still active.

I found out that ComponentSpace SSO Session Timeout can be configured by DistributedSsoSessionStoreOptions.SlidingSessionExpiration and we can set a large value there (like 24 hours). But it seems like a workaround. And it leads to a bigger size of Session storage table.
I see that SSO Session is prolonged when working with it. But in our case, it happens only on login and logout actions.   

Maybe I am missing something? How did it suppose to work?
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
Your understanding is correct. Normally SAML session state is only accessed at SSO and SLO. If sufficient time has elapsed since SSO, the SAML session state will have expired and been removed from the session store. In this case SLO cannot occur.

There are a few options for avoiding this issue.

1. Set a long DistributedSsoSessionStoreOptions.SlidingSessionExpiration as you have done. The downside is that the session store will grow in size if SLO doesn't occur.

2. If CanSLO returns false, prompt the user to close the browser. This will clear the IdP session state as well.

3. Call ISamlProvider.GetStatusAsync on a regular basis to reset the sliding expiration.

4. Store the SAML session state in the ASP.NET session using the AspNetSsoSessionStore. This assumes ASP.NET sessions are enabled and stored in a central database etc.

If you have any alternative ideas, please let us know.

Regards
ComponentSpace Development
Serhii Krut
Serhii Krut
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 13
ComponentSpace - 8/11/2020
Your understanding is correct. Normally SAML session state is only accessed at SSO and SLO. If sufficient time has elapsed since SSO, the SAML session state will have expired and been removed from the session store. In this case SLO cannot occur.

There are a few options for avoiding this issue.

1. Set a long DistributedSsoSessionStoreOptions.SlidingSessionExpiration as you have done. The downside is that the session store will grow in size if SLO doesn't occur.

2. If CanSLO returns false, prompt the user to close the browser. This will clear the IdP session state as well.

3. Call ISamlProvider.GetStatusAsync on a regular basis to reset the sliding expiration.

4. Store the SAML session state in the ASP.NET session using the AspNetSsoSessionStore. This assumes ASP.NET sessions are enabled and stored in a central database etc.

If you have any alternative ideas, please let us know.

Thanks for the quick response and provided options.
Unfortunately, #2 is not an option, because of the business needs. And #4 won't work since the application doesn't use ASP.NET session.
#3 may work for us.
But for now, we decided that we will stick with #1 and see how it goes.
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
Thanks for the update.

Regards
ComponentSpace Development
GO


Similar Topics


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


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search