topic Re: SSO must be invalidated after Session Timeout in Application Development and Automation Discussions

SSO must be invalidated after Session Timeout

Former Member — Thu, 23 Dec 2010 22:35:04 GMT

We have a requirement to kick out idle users in the EP after 30 minutes of idle time. The value in the web.xml for "Session timeout" is 30 minutes which timeouts idle users; however, just by clicking "Refresh" in the browser allows the end-user to regain session,

I understand that this is probably being the SSO ticket still valid (ume.admin.login.ticket_lifetime) being set to 8 hours, but setting this 30 minutes would regularly prompt end-users for their password regardless if idle or not.

Any takers?

Re: SSO must be invalidated after Session Timeout

Former Member — Thu, 23 Dec 2010 23:11:29 GMT

I have seen some documentation on "single-logout" and "keepalive" settings which was SSO related for Java stacks, but did not look further into it. Would be a good search term to follow-up on.

Is your problem session IDs or is the refresh a problem for a statefull application on the server side?

Cheers,

Julius

Re: SSO must be invalidated after Session Timeout

Former Member — Fri, 24 Dec 2010 07:14:50 GMT

Hi Chris,

We have a requirement to kick out idle users in the EP after 30 minutes of idle time. The value in the web.xml for "Session timeout" is 30 minutes which timeouts idle users; however,

just by clicking "Refresh" in the browser allows the end-user to regain session.

When user clicks Refresh the session will be active. This means that the user is not idle and is aware that he/she needs the session to perform some activity. The session timeout setting is basically for the idle and inactive sessions. This way, the resources can be managed more effectively. When user needs the session, why you want to kill it?

SSO ticket still valid (ume.admin.login.ticket_lifetime) being set to 8 hours, but setting this 30 minutes would regularly prompt end-users for their password regardless if idle or not.

The ticket_lifetime is the SSO ticket and ofcourse, if you change the value to 30 minutes, it will prompt the user to validate the credentials repeteadly. Changing this is not advised.

As per my understanding your settings are appropriate and doesn't require any changes. The only thing you should make is to educate your managers on what I've explained

Cheers & happy new year!!

Raghu

Re: SSO must be invalidated after Session Timeout

Former Member — Fri, 24 Dec 2010 10:53:09 GMT

Hi,

Please refer the Wiki at the link below which gives a good proactive approach to inform idle users about the inactivity and specifies the timelimit (in case you have set ume.admin.login.ticket_lifetime as 8 hours) within which it can be re-activated. With this approach you can even decide upon the timeperiod after which user's session would be considered as idle.

[http://wiki.sdn.sap.com/wiki/display/EP/EPSnippet-Portaluseridletimeoutforlogoff-custom+javascript]

Thanks

Sandipan

Edited by: Sandipan Choudhury on Dec 24, 2010 4:23 PM

Re: SSO must be invalidated after Session Timeout

Former Member — Sat, 25 Dec 2010 08:17:38 GMT

This seems to be a very promising approach; I will forward this to our developers and will update you.

Re: SSO must be invalidated after Session Timeout

Former Member — Sat, 25 Dec 2010 08:26:14 GMT

I haven't gone through the jsession ID. Any related route I can explore?

Users shouldn't be able to regain session after he/she was timed-out regardless of the application.

Re: SSO must be invalidated after Session Timeout

Former Member — Sat, 25 Dec 2010 08:39:39 GMT

The requirement would lessen unauthorized access to unattended browsers.

Yes, we do understand that editing the sso lifetime is not the exact solution but it is the closest we got. For now, we will explore the script presented in the link above.

Re: SSO must be invalidated after Session Timeout

Former Member — Mon, 03 Jan 2011 16:28:08 GMT

We will be sticking with changing the lifetime of the SSO ticket. The custom script seems to be a nice approach but we aren't just adventurous enough to go through it.

It is just a pity that SAP doesn't seem to have a "standard" way to do this.

Closing thread.