Introduction
As we know the Enterprise Portal (EP) from a high level perspective can become quite a complex session environment for users over a time-period due to increased utilization of resources such as applications, data management provisions and documents. With each user session enacted on the Portal comes a set of different connection requests which are handled by the Portal's session management mechanisms.
How Sessions Are Handled
When session expires or logoff is invoked or browser is closed, no matter what, the connection is not terminated but returned to the pool and kept open as defined in the Connection Lifetime property. In short, the connection stays open for the predefined amount of time by design and this is not an unexpected behavior. It remains in the pool, it is no longer used by another service e.g. the UWL and it is available for other clients. When executing the ITS services that access a component system (R/3) in the portal, there is the question how to close the sessions in the component system when the user closes the browser (the HTTP protocol is considered to be stateless). When the user closes the browser window or navigates to another position, the browser sends a mass request to a dedicated portal component to end one or more open sessions (by default DSM.Terminator). This component distributes the corresponding termination commands to the component systems. The Termination command then closes the server session.
Session Inactivity & Automatic Timeouts
Lets imagine you are searching for a means of an "idle" session timing itself out for example:
- User A Logs in
- User A performs some navigation through ESS/MSS Applications and lands on one single iView
- No further action is performed for a period of e.g. 3 minutes
Business preference would like such a session to be ended automatically after these "3 idle minutes". From a high level viewpoint the desire behind wanting this session to end automatically comes down to the most obvious reasons i.e. security and session authorization. Company best practice does not wish to have one user leaving a session open for another user to simply "walk into" and carry on as this would be a breach of practice and standards.
- Prevention is the best form of protection
Can We Configure Automatic Timeouts?
There is a suitable means of achieving such behavior but this arrives with some small limitations. Let us firstly remember how the "Timeout" happens generally for the Enterprise Portal. Such a "Timeout" occurs in two ways:
- Session Timeout
- Ticket Timeout
The default value of Ticket Timeout is 8 hrs and it over-rides the value for session timeout, meaning, that even if the session has timed out e.g. after 30 minutes, the logon ticket is still valid and so there will be no need for a user to re-login.
On the other hand, if the ticket has timed out and even if the user session is still valid, then it will force a timeout.
Therefore the "Ticket Timeout" is the mechanism supporting the concept of an automatic means of session closure. It is often the case that Netweaver (AS Java) has a timeout option of 30 minutes but it can be changed to 10 minutes (for a timeout due to an inactive user having no interaction with the Portal)in some cases.
So what about "Idle" Timeouts?
In theory the concept of an idle Timeout is not supported.The Portal itself is used as a gateway to other applications (SSO). As a user set to be active in an application loaded in an isolated iframe (which the portal framework is not aware of), then having a logoff based on Portal idle time would result in an unsatisfactory behavior in the back-end application e.g. a sudden loss of SSO sessions despite the user being active in this application.
- This restriction still applies - there is no standard feature to offer a logoff based on idle time.
"Idle" Timeouts & Custom Approaches
In my experience I have come across several scenarios in which custom implementations provided the desired result for customers achieving this idle timeouts in the Portal Setup. For example a good working example would be for an inactive session to "timeout" and then subsequently "redirect" the closing session to the Portal Login Page. This would ensure all security standards are conformed to and maintain ease of access with the Portal.
"Idle" Timeouts & Custom Approaches (ii)
This idle timeout is achieved via custom Javascript covered in the following SCN Article outlined for cross-reference purposes.
- http://wiki.scn.sap.com/wiki/display/EP/EP+Snippet+-+Portal+user+idle+timeout+for+logoff+-+custom+ja...
Remember the approach above is custom and does NOT come with formal support documentation or guidance procedures. If this approach interests you I would recommend looking into some of the limitations existing in association to the (custom) portal idle session timeout. A complete overview (yahoo interface) can be found using the link outlined below.
- http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/309379b6-bb9b-2d10-feb1-91f2a7078...
With timeouts regarding idle user sessions a timeout can be managed through the following patch Global properties > Tools > Session Timeout or by the use of a custom masthead. The links provided are the best example overviews currently available as there is limitations as to what you one may customize. Once a user performs a logoff their session goes into a suspend state or is cached in case they decide to log in again shortly.
- This is why the session information is displayed in SM04 on hour afterwards.
Remember that logoff from the portal is based on the ticket session, configured using the login.ticket_lifetime. It is not related to the http session itself or the security session or the J2EE connectors.
The ticket always has a fixed lifetime and does not expire due to user idleness and a user session will not time out due to inactivity.
If you want to adjust the expiration time of the SAPlogon ticket, this can be achieved through the property of "Lifetime of SAP Logon Ticket (hh:mm)" in "Security settings" at - System Administration > System Configuration > UM Configuration.
- Note: The session will eventually expire after this time setting, even if the user is not idle. The user needs to renew the ticket after expiry. This is the way Web Based Applications manages sessions.
- There are no plans to change this as it would involve redesigning the Web Application Server.
It is currently formal means of supporting the SSO functionality. You can take a look at Note 620207 for more information.
In Summary
Basically, there is no FORMAL way to implement a timeout in the Portal based on idleness. In relation to the WIKI's stated previously they will provide you with an insight into setting a "given time" timeout. If you want the Security Session also to expire automatically at some shorter time than the default (about 27 hours), then you should also need the SessionExpirationPeriod (Visual Administrator -> server ->Services Security Provider -> Properties tab)
When the user temporarily stops using the Portal, the SSO ticket expires but he/she SHOULD be able to use EP within the allocated TICKET timeframe, because the J2EE Server finds its coinciding Security Session via http session id (JSESSIONID).
You can change the session timeout for the Portal by opening the file through the following navigation path:
- /usr/sap/<SID>/<inst>/j2ee/cluster/server0/apps/sap.com/irj/servlet_jsp/irj/root/WEB-INF/web.xml
The change is performed via the line:
- <session-timeout>45 </session-timeout> if there is no session-timeout tag presented, please add the following lines just before </web-app> tag: <session-config> <session-timeout>45 </session-timeout> </session-config>
Additional guidance can be found here:
If you face any session management issues such as "session retention" or backend sessions remaining open for end users I would recommend consulting the blog series I wrote on these topics which provide an informative overview on how to troubleshoot and resolve such an occurrence.
EP: Sessions Part 1 (RFC, GUI, HTTP Plugin) A Brief Overview
- troy.cronin2/blog/2016/02/01/ep-sessions-part-1-rfc-gui-http-plugin-a-brief-overview
- SAP Managed Tags:
9 Comments
