EP: Portal – Idle Session Timeouts?
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.
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.
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
EP: Sessions Part 2 (RFC, GUI, HTTP Plugin) Common Grounds & Issues
EP: Sessions Part 3 Frequest Issues & Solutions
Hello Troy,
I really like that you address a lot of different topics in your blogs and I think they are well explained and helpful in general.
But I want to give you two pointers from a reader’s (and user of this information’s) perspective to make them even better:
If you just use them to emphasize information you should hold back on this or it’s kind of “all of this is important”. And that takes away the purpose of using color. 😉
I, for example, like to use bold and italic to emphasize text and only grab some color for the reeeaaally important stuff that needs to jump out.
If you could provide the information with the versions included (for example “This is for EP 7.01.”) and (even better) also write down where this is found in the other EP versions, that are commonly still in use, it would be really helpful.
So to conclude: I think you do a nice job with your blogs and I see that you put a lot of thought and effort into them, but I know you can do even better! 🙂
Regards,
Steffi.
Hey Steffi
Firstly many thanks for the constructive feedback it is greatly appreciated 😎 and welcomed with open arms 😆 .
In relation to your queries surrounding the color structure let me shed some light upon this. The "color-coding" itself does not represent any particular signified elements or opinion phrases etc. You are indeed correct they are used merely to emphasize and highlight the core/key points dependent on the topic the blog relates to. In this instance we are dealing with sessions and the Portal which is as you know quite a broad spectrum and has proven to be the base of a lot of Incidents I've worked on in the past as an Engineer.
Secondly regarding the version this is a great point and definitely one I will implement in future blog postings. As we move towards 2017 older NW Versions will no longer be supported therefore the contrast between property/parameter locations will be cut drastically which is a good thing. Although I agree with you 100% and will definitely implement this idea.
I would like to thank you so much for the feedback as without this I would not improve my blogging 🙂 .
Thank you so much again it is greatly appreciated.
P.S. my next blog will be dedicated to you 🙂
Troy, if I were you I'd remove all the colors ASAP. No one cares what's the excuse or idea behind it when your text is unreadable. I applaud Steffie's ability to read this as I had to stop on the first paragraph to avoid damage to my eye sight. Seriously, have some consideration for the readers.
Hi Jelena
Many thanks for the productive & straight feedback, greatly appreciated 🙂 . I'll heed your advice and revert the font color to a more neutral display so its clearly legible. My idea was to help illustrate the different aspects of this particular topic but perhaps you are moderately correct and the coloring itself is a major drawback.
I agree and will make the change accordingly. Thanks again for the feedback and happy reading in the future 🙂 .
Hello Troy,
to show the different aspects or have a kind of "those are the core points" you could create a cloud with those words and put it at the start of your blog with the hint, that you'll explain all of those and their connections to eachother in the following text.
Kind of like a teaser picture. That one could be as colorful as you like. 🙂
Regards,
Steffi.
Hey Steffi
I'm going to take you up on that idea 🙂 and make use of some SmartArt 🙂 .
Thank you again for all the feedback, greatly appreciated !
Have a great day & happy blogging 😎
Kind Regards
Troy
Hi Troy,
thank you very much for the excellent blog!
I tried to understand and test the processes you described arround authentication and timeouts but I'm a little bit confused.
I'm looking for a solution to force a user to login new after a specific time period.
Here's the scenario (quite simple) and I'd ask you kindly for some explanation/help:
- A User logs into EP (NW7.3), he's allowed to work in EP for 1h
- after 1h the next request should be not accepted (authentication expired) and redirected to the EP login page to login again
I tried to set the parameter login.ticket_lifetime to 1h (EP->System configuration -> UME configuration -> expert mode) but it's not working as expected.
The MYSAPSSO2-cookie validity expires (like expected), but the EP still accepts the request.
Until I read your blog, I thought the change of the parameter login.ticket_lifetime would be sufficient. But along to your blog now I understand that's not the whole Story and some sessions timeouts/expiration periods coming into game.
Two questions:
1) How can I configure the described demand (please don't think about the business point of view, only the technical solution should be cleared)
2) In your blog you talk about a 'security session', a 'SessionExpirationPeriod', a 'session timeout' and a 'allocated ticket timeframe'. Would you please explain how they work together concerning
the EP's processing a incoming request?
Thanks in advance & Best Regards
Thomas
Hi Troy,
Thanks for this nice blog Have the same requirement to have auto time out if use ris idle for sometime in portal.
In your blog you mentioned:
This idle timeout is achieved via custom Javascript covered in the following SCN Article outlined for cross-reference purposes.
However this link doesn't work. Could you please check and share again like how can I implement this?
Thanks in advance. Regards.
Manish Gupta
EP Snippet - Portal user idle timeout for logoff - custom javascript for NW 7.0 - Portal - Support Wiki (sap.com)