SSO Session Timeout works incorrectly
Asked Answered
P

2

8

I'm trying to configure session timeout using WSO IS 5.1.0.
I have one Service Provider, which has session timout 10 minutes.
I've configured SSO sesison timeot to 10 minutes in WSO2 is using Managment console on Resident Identity Provider section.

I don't know why, but the global configuration (<IS_HOME>/repository/conf/identity/identity.xml file under the <TimeConfig> element) doesn't work.

After local session timeout, user is redirected to the SSO login page, so it seems like global session is invalidated. But if you type the app url in browser (again), user is redirected to the login page, reauthenticated automatically, and redirected to the last visited page. Why the first time user gets to the SSO login page, and after that - not? Expected behavior is that user should't be reauthenticated after global session expired.

So, the scenario is:
- User goes to Service provider's home page and gets redirected to SSO login page
- User do login on SSO login page
- After some time SSO Session expires;
- Service provider's session expires as well - user goes to some Service Provider's page and get's redirected to the SSO login page (it seems like at this point SSO session is somehow recreated)
- user tries again to go to Service Provider's page and he is magically reathenticated (because session was recreated).

I will appreciate if you at least comment this flow, I'm now sure if I understand how it works

Psychometry answered 29/4, 2016 at 16:0 Comment(0)
R
1

I tested the same with WSO2 IS 5.1.0 version, and the issue that you have noted exists. While going through, I noted that this also has been caused due to the issue noted at IDENTITY-4537 on timestamp calculation logic. This has been fixed in the coming release, WSO2 IS 5.2.0

Rowan answered 12/5, 2016 at 11:36 Comment(0)
R
-1

The session timeout global configuration in <IS_HOME>/repository/conf/identity/identity.xml file is overridable from the management console.

Once you configure the session time out from the management console that gets applied to the logged in tenant and that takes the precedence over the global configuration.

So in a fresh IS 5.1.0 pack, if you have logged into the management console with 'admin' user and if you have configured the 'Idle Session Time Out' of the 'Resident Identity Provider' you have changed the session time out of the super tenant which is identified as 'carbon.super'.

So when the service providers configured in this tenant participates in an authenticated session of a user of this tenant, the session timeout will be value that you just configured.

Ideally, what that means is, in IS 5.1.0 we cannot configure the session time out of the Identity Provider, per Service Provider. It can only be changed per tenant. Further, the 'Idle Session Time Out' configured at the 'Resident Identity Provider' in the management console denotes the session timeout of an authenticated session, created for the end user, who authenticates for a Service Provider application via some authentication protocol (SAML, OpenID, OpenIDConnect, etc .). This is different from the management console login session.

I'm not very clear about the two terms you are using, 'local session time out' and 'global session timeout'. But hope my explanation above may help you.

For more information on how SSO session is managed in WSO2 IS 5.1.0 please refer [1].

[1] http://malithiedirisinghe.blogspot.com/2016/01/how-to-manage-authenticated-session-in.html

Rowan answered 4/5, 2016 at 9:13 Comment(4)
thank you! By "global session timeout" I mean SSO session timeout, and "local session timeout" is Service Provider's session timeout. I have configured SSO session timeout at the 'Resident Identity Provider'. But the problem is that when user goes to some Servise provider's page after global session (SSO) expired, he is redirected to the login page, (so it looks like everything is fine) but if he tries after that type some app's page in a browser, he will be reauthenticated (although the session is dead and he haven't logged in again)Psychometry
This is what I can reproduce as well with the same session timeouts: User is redirected to the SSO Login page (when attempting to access the Service provider app), but without even entering the credentials he can manually open the service provider app again in a new tab and he will succeed. For me this looks like a bug. When the user is redirected to the SSO page - his samlssoTokenId Cookie expiration date gets updated (if this helps).Barbwire
I tested the same with WSO2 IS 5.1.0 version, and the issue that you have noted exists. While going through, I noted that this also has been caused due to below issue on timestamp calculation logic. IDENTITY-4537. This has been fixed in the coming release, WSO2 IS 5.2.0Rowan
@MalithiEdirisinghe thank you! you can add this as answer, I will accept itPsychometry

© 2022 - 2024 — McMap. All rights reserved.