Expected behavior for session timeout

[j***@hotmail.com]

Hello,

I need to get confirmation from someone who knows exactly what type of behavior WebSphere will exhibit when a session times out. That is, a user logs in successfully to the application, no activity is performed for a period long enough to have their session become invalid due to timeout, the user tries to do something (refresh page, submit a form from current page, go to another page, etc): what should happen?

It seems to me that WebSphere would redirect the user back to the application's login page by default so that he must authenticate again to re-enter the application. This is what was happening before for our application when deployed in a remote server environment, but it is not happening now. For example, the user's session times out, the user refreshes the page that he is on at that time and he is NOT redirected back to the login page. Instead, the current page refreshes along with a new session being created by WebSphere.

This does not happen in my local WSAD 5.1 test environment when using the same code that is deployed on a local test server: WebSphere redirects me back to the login page to make me re-authenticate, which is what I would expect. Also, the problem did not happen before in any of our remote environments. We're using form-based authentication and IBM's implementation thereof.

Any thoughts on this will certainly help. Thanks.

Jeff

[Ken Hygh]

Post by j***@hotmail.com
Hello,
I need to get confirmation from someone who knows exactly what type of behavior WebSphere will exhibit when a session times out. That is, a user logs in successfully to the application, no activity is performed for a period long enough to have their session become invalid due to timeout, the user tries to do something (refresh page, submit a form from current page, go to another page, etc): what should happen?
It seems to me that WebSphere would redirect the user back to the application's login page by default so that he must authenticate again to re-enter the application. This is what was happening before for our application when deployed in a remote server environment, but it is not happening now. For example, the user's session times out, the user refreshes the page that he is on at that time and he is NOT redirected back to the login page. Instead, the current page refreshes along with a new session being created by WebSphere.
This does not happen in my local WSAD 5.1 test environment when using the same code that is deployed on a local test server: WebSphere redirects me back to the login page to make me re-authenticate, which is what I would expect. Also, the problem did not happen before in any of our remote environments. We're using form-based authentication and IBM's implementation thereof.
Any thoughts on this will certainly help. Thanks.
Jeff

Jeff,
Logging in and session have nothing to do with each other.

Ken

[j***@hotmail.com]

Post by Ken Hygh
Jeff,
Logging in and session have nothing to do with each
other.
Ken

Ken,

I'm not suggesting that they are related--I'm just explaining at what we've experienced and am asking if anyone knows what should happen in WebSphere when a user's session times out. That is, if WebSphere has some sort of default behavior that kicks in automatically when a session times out and the user tries to do something, what is it? From what I've seen, it appears that WebSphere will send the user back to the application's login page by default thereby forcing the user to authenticate again to get back into the application. That is the part for which I am unclear and am in need of assistance (b/c that's not happening for our app when deployed in a remote server environment).

Jeff

[Paul Ilechko]

Post by j***@hotmail.com

Jeff, Logging in and session have nothing to do with each other.
Ken

Ken,
I'm not suggesting that they are related--I'm just explaining at what
we've experienced and am asking if anyone knows what should happen in
WebSphere when a user's session times out. That is, if WebSphere has
some sort of default behavior that kicks in automatically when a
session times out and the user tries to do something, what is it?
From what I've seen, it appears that WebSphere will send the user
back to the application's login page by default thereby forcing the
user to authenticate again to get back into the application. That is
the part for which I am unclear and am in need of assistance (b/c
that's not happening for our app when deployed in a remote server
environment).

WebSphere will not do *anything* by default - the user is still logged
in provided they still have a valid LTPA cookie; the application will
have to handle invalid session.

[Sunit Patke]

Jeff,

I think what WAS does is expire the session object. It is up to the
application developer to design the application behavior.

In your case if the page refreshes with a new session being created then you
might be using getSession(true) instead of getSession(false).
In the first case if the session exists a reference to it is returned and if
it does not exist then a new session is created. In the second case if the
session exists then reference to it is returned but if it does not then a
new session is not created and a null is returned.

Sunit

Post by j***@hotmail.com
Hello,
I need to get confirmation from someone who knows exactly what type of
behavior WebSphere will exhibit when a session times out. That is, a user
logs in successfully to the application, no activity is performed for a
period long enough to have their session become invalid due to timeout,
the user tries to do something (refresh page, submit a form from current
page, go to another page, etc): what should happen?
It seems to me that WebSphere would redirect the user back to the
application's login page by default so that he must authenticate again to
re-enter the application. This is what was happening before for our
application when deployed in a remote server environment, but it is not
happening now. For example, the user's session times out, the user
refreshes the page that he is on at that time and he is NOT redirected
back to the login page. Instead, the current page refreshes along with a
new session being created by WebSphere.
This does not happen in my local WSAD 5.1 test environment when using the
same code that is deployed on a local test server: WebSphere redirects me
back to the login page to make me re-authenticate, which is what I would
expect. Also, the problem did not happen before in any of our remote
environments. We're using form-based authentication and IBM's
implementation thereof.
Any thoughts on this will certainly help. Thanks.
Jeff

[j***@hotmail.com]

Sunit,

Post by Sunit Patke
I think what WAS does is expire the session object.

I know WebSphere is invalidating the sessions when they time out b/c I can see our output in the log file, which is written as part of the implementation of our session listener class's sessionDestroyed() method.

Post by Sunit Patke
In your case if the page refreshes with a new session
being created then you
might be using getSession(true) instead of
getSession(false).

We are not using either of those methods.

I am asking, specifically, about the exact behavior of WebSphere and what it will do after a session times out and the user tries to do something in the application. I suspect WebSphere should redirect the user to the application's login page. That is what I'm trying to ascertain.

Jeff

[Ken Hygh]

Post by j***@hotmail.com
Sunit,

Post by Sunit Patke
I think what WAS does is expire the session object.

I know WebSphere is invalidating the sessions when they time out b/c I can see our output in the log file, which is written as part of the implementation of our session listener class's sessionDestroyed() method.

Post by Sunit Patke
In your case if the page refreshes with a new session
being created then you
might be using getSession(true) instead of
getSession(false).

We are not using either of those methods.
I am asking, specifically, about the exact behavior of WebSphere and what it will do after a session times out and the user tries to do something in the application. I suspect WebSphere should redirect the user to the application's login page. That is what I'm trying to ascertain.
Jeff

the exact behavior is nothing. WebSphere will not redirect any requests
based on creating a new session object.

Ken

[Ben_]

Hello,

As stated by Ken, session and authentication are separate things.

If the session is valid but the credentials are expired, you get the login
page. If the credentials did not yet expire, but the session already did,
you can access the page. That the user has a session or not. How must the
application react ? Just like when there is no security: one can access any
page without necessarily going through a certain workflow, and the
application developer has to live with this.

This may sound weird at first, but in an SSO context, it's logical. In an
SSO domain, the credentials are valid for an extended period of time (longer
than the session), you don't want to go to the login page all the time.

I assume the difference in behavior you see comes from the fact that WSAD
has WAS Base version (and SWAM as authentication mechanism) and the other
platform is WAS-ND (with LTPA as authentication). I don't know the internals
of SWAM, but for LTPA you can see your browser has received an LTPAToken
cookie.

HTH.

[j***@hotmail.com]

Ben, thank you. This information has been very helpful. The differences between my local environment and what is defined at the server level for our remote environments is as you thought with regard to SWAM versus LTPA usage, but I don't understand all of the details yet. Some comments and questions are below.

Post by Ben_
As stated by Ken, session and authentication are
separate things.

Thanks, I have a better understanding now and can see how I was probably confusing others in my earlier postings.

Post by Ben_
If the session is valid but the credentials are
expired, you get the login
page. If the credentials did not yet expire, but the
session already did,
you can access the page.

The credentials, I'm assuming, are related to security. What are they exactly and how would I know where to find them, if possible, or determine how and when they're supposed to expire?

Post by Ben_
That the user has a session
or not. How must the
application react ? Just like when there is no
security: one can access any
page without necessarily going through a certain
workflow, and the
application developer has to live with this.

Ok, but I'm just wondering why we're suddenly seeing the problem I've described in our remote environments. Before it seemed like as soon as a user's session would expire due to timeout, that user would be directed back to the login page by WebSphere as soon as they would try to do something (from whatever the last page was that they were on when their session timed out). Any ideas on what would cause the sudden change in behavior?

Post by Ben_
This may sound weird at first, but in an SSO context,
it's logical. In an
SSO domain, the credentials are valid for an extended
period of time (longer
than the session), you don't want to go to the login
page all the time.
I assume the difference in behavior you see comes
from the fact that WSAD
has WAS Base version (and SWAM as authentication
mechanism) and the other
platform is WAS-ND (with LTPA as authentication).

In my local server environment, there isn't anything configured for LTPA, which makes sense because SWAM is specified as the active authentication mechanism for security. However, I noticed that SSO is listed as an additional property of LTPA, and it is enabled in my local. The remote servers are set up to use LTPA and also have SSO enabled. Do you know what the difference might be, if any, since SSO is shown as enabled in both environments?

Post by Ben_
I
don't know the internals
of SWAM, but for LTPA you can see your browser has
received an LTPAToken
cookie.

I tried to located the LTPAToken cookie but haven't been able to find it yet. I've looked in:

C:\Documents and Settings\myName\Cookies
C:\Documents and Settings\myName\Local Settings\Temporary Internet Files

Do you know if the LTPA cookie is created as soon as you authenticate successfully? Any ideas on how it might be named or where it would be located? Of course I found a number of ***@foo.txt cookies but don't know which one might be the right one.

Thanks

[Ben_]

<snip/>

Post by j***@hotmail.com
The credentials, I'm assuming, are related to security. What are they
exactly and how would I know where to find them, if possible, or determine
how and when they're supposed to expire?

Credentials are the assertion of your identity and profile by the
authentication system your application uses and trusts. Once user has been
authenticated, the authentication system won't check all the time who you
are and what you can do from the User Registry, but rather lookup credential
information from its cache and give the user a security token. With
LTPA security, the token is in the form of a (memory) cookie (named
LTPAToken, IIRC) containing encrypted information. Expiration of the
credentials cache is configurable.

<snip/>

Post by j***@hotmail.com
Ok, but I'm just wondering why we're suddenly seeing the problem I've
described in our remote environments. Before it seemed like as soon as a
user's session would expire due to timeout, that user would be directed

back

Post by j***@hotmail.com
to the login page by WebSphere as soon as they would try to do something
(from whatever the last page was that they were on when their session

timed

Post by j***@hotmail.com
out). Any ideas on what would cause the sudden change in behavior?

"Before" ? But before what ? What platform did you use "before" ?

<snip>/

Post by j***@hotmail.com
In my local server environment, there isn't anything configured for LTPA,
which makes sense because SWAM is specified as the active authentication
mechanism for security. However, I noticed that SSO is listed as an
additional property of LTPA, and it is enabled in my local. The remote
servers are set up to use LTPA and also have SSO enabled. Do you know

what

Post by j***@hotmail.com
the difference might be, if any, since SSO is shown as enabled in both
environments?

I don't know how SWAM is implemented. The InfoCenter should have details.

[j***@hotmail.com]

<snip/>

Post by j***@hotmail.com
out). Any ideas on what would cause the sudden
change in behavior?
"Before" ? But before what ? What platform did you
use "before" ?

We've been using the same platform, but what I meant by "before" is that it seems like the expiration of our credentials was happening right when a user's session would expire, and now that doesn't seem to be the case. I can't say that with absolute certainty b/c it wasn't something we were testing for, specifically, but it is to the best of our team's recollection that that was how things were working until recently.

I'm looking in the WebSphere documentation to try to learn more about the topics being discussed. Thanks again for the info.

Jeff

[Larry Schweyer]

I was following this thread, and quite by coincidence, found the following
whilst browsing developerWorks.
Question: I want to force my users to re-login after a set "inactivity
timeout" period. How is WAS supposed to work with regard to session timeouts
and LTPA timeouts?

Answer: The WebSphere Application Server LTPA token expires based on the
lifetime of the login session, not based upon inactivity. Thus, the
WebSphere Application Server login session will not expire if the user
performs no action for some period of time. However, the HTTPSession does
expire based upon inactivity. If in your application you need to expire the
use of an application based on idleness, you have to explicitly code this in
your application. You can capture when a user arrives with an expired
session (really a new session) and force them to login again if you think
this is necessary. Keep in mind that doing this undermines Single Sign On
across applications.



I found it here:
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0410_botzum/0410_botzum.html

Post by Ben_
<snip/>

Post by j***@hotmail.com
out). Any ideas on what would cause the sudden
change in behavior?
"Before" ? But before what ? What platform did you
use "before" ?

We've been using the same platform, but what I meant by "before" is that

it seems like the expiration of our credentials was happening right when a
user's session would expire, and now that doesn't seem to be the case. I
can't say that with absolute certainty b/c it wasn't something we were
testing for, specifically, but it is to the best of our team's recollection
that that was how things were working until recently.

Post by Ben_
I'm looking in the WebSphere documentation to try to learn more about the

topics being discussed. Thanks again for the info.

Post by Ben_
Jeff

[j***@hotmail.com]

Post by Larry Schweyer
I was following this thread, and quite by
coincidence, found the following
whilst browsing developerWorks.
Question: I want to force my users to re-login after
a set "inactivity
timeout" period. How is WAS supposed to work with
regard to session timeouts
and LTPA timeouts?

<snip/>

Post by Larry Schweyer
http://www-128.ibm.com/developerworks/websphere/librar
y/techarticles/0410_botzum/0410_botzum.html

After reading information in that link and in the other replies within this thread, I also found the article "HOW-TO: Setting WAS timeout", which I think is applicable to this discussion. It is listed on IBM's site as a Technote (FAQ):

http://www-1.ibm.com/support/docview.wss?rs=1016&context=SS2GQV&dc=DB520&uid=swg21188935&loc=en_US&cs=UTF-8&lang=en

The desire (amongst the project team) is to force users to log in again after their HTTP session has expired. From what I understand thus far, I'm going to lower the expiration timeout period for the LTPA token so that it is closer or equal to our session timeout and see what happens.

I'll reply with my findings afterwards for those (like myself) who are unsure as to what will result.

Jeff

[Paul Ilechko]

Post by j***@hotmail.com

Post by Larry Schweyer
I was following this thread, and quite by coincidence, found the

The desire (amongst the project team) is to force users to log in
again after their HTTP session has expired.

This is OK if you only have one application. But think about it - if you
have several apps and you want them to log on once to all apps (which is
the SSO that LTPA provides) then anytime the HTTP session for *any*
application expires, you are going to kick the user out of *all* their
applications. Does this make sense ?

Post by j***@hotmail.com
From what I understand
thus far, I'm going to lower the expiration timeout period for the
LTPA token so that it is closer or equal to our session timeout and
see what happens.

This is meaningless, as the session timeout is usage-based, and the LTPA
timeout is absolute. You'll just make your users log in more often, even
if they are active.

[Ben_]

Post by Paul Ilechko

Post by j***@hotmail.com

Post by Larry Schweyer
I was following this thread, and quite by coincidence, found the

The desire (amongst the project team) is to force users to log in
again after their HTTP session has expired.

This is OK if you only have one application. But think about it - if you
have several apps and you want them to log on once to all apps (which is
the SSO that LTPA provides) then anytime the HTTP session for *any*
application expires, you are going to kick the user out of *all* their
applications. Does this make sense ?

I second this.

Post by Paul Ilechko

Post by j***@hotmail.com
From what I understand
thus far, I'm going to lower the expiration timeout period for the
LTPA token so that it is closer or equal to our session timeout and
see what happens.

This is meaningless, as the session timeout is usage-based, and the LTPA
timeout is absolute. You'll just make your users log in more often, even
if they are active.

I second this as well. :-)

The way LTPA works has implications you must be aware of. As Paul said,
session timeout is reset each time user activity happens, but token timeout
is absolute. If you log at 10:00 AM and the timeout is 30 minutes, you'll
have to login again, whatever intensive your activity is. So the lower the
timeout, the more often you must (re-)login. You don't loose your session
however. The higher the timeout, the longer the period a user can log into
the system, after his account was locked in the User Registry, for example.

[j***@hotmail.com]

Post by j***@hotmail.com

Post by Paul Ilechko

Post by j***@hotmail.com
The desire (amongst the project team) is to force

users to log in

Post by Paul Ilechko

Post by j***@hotmail.com
again after their HTTP session has expired.

This is OK if you only have one application. But

think about it - if you

Post by Paul Ilechko
have several apps and you want them to log on once

to all apps (which is

Post by Paul Ilechko
the SSO that LTPA provides) then anytime the HTTP

session for *any*

Post by Paul Ilechko
application expires, you are going to kick the user

out of *all* their

Post by Paul Ilechko
applications. Does this make sense ?

I second this.

I third that as well. I was thinking about it last night after I went home and thought that making the change would affect all of the application servers, which wouldn't be good. Hey project ABC, guess what we just did?

Post by j***@hotmail.com

Post by Paul Ilechko

Post by j***@hotmail.com
From what I understand
thus far, I'm going to lower the expiration

timeout period for the

Post by Paul Ilechko

Post by j***@hotmail.com
LTPA token so that it is closer or equal to our

session timeout and

Post by Paul Ilechko

Post by j***@hotmail.com
see what happens.

This is meaningless, as the session timeout is

usage-based, and the LTPA

Post by Paul Ilechko
timeout is absolute. You'll just make your users

log in more often, even

Post by Paul Ilechko
if they are active.

I second this as well. :-)
The way LTPA works has implications you must be aware
of. As Paul said,
session timeout is reset each time user activity
happens, but token timeout
is absolute. If you log at 10:00 AM and the timeout
is 30 minutes, you'll
have to login again, whatever intensive your activity
is. So the lower the
timeout, the more often you must (re-)login. You
don't loose your session
however. The higher the timeout, the longer the
period a user can log into
the system, after his account was locked in the User
Registry, for example.

That part I didn't realize so now I'm wondering what options are left. Info from the one security-related article that was posted earlier stated "..You can capture when a user arrives with an expired session (really a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines Single Sign On across applications". I don't like the thought about undermining WebSphere functionality (for which I'm still I'm the early phases of trying to understand) that was built for a specific purpose, and I certainly don't want to do it across applications. My feeling at this point is to make the argument for leaving it as it is and explaining the reasons and benefits for doing so.

One suggestion from another teammate was to try to invoke IBM's form-based logout functionality (ibm_security_logout action) somehow when the user's session expires, but I don't know where to place the code for doing that. Plus, trying to figure out "here's the user's session now, but it's not the one they started with (meaning it *might* have become invalid due to inactivity and not for some other reason) so log them out" in order to trigger the logout doesn't sit well with me.

What would you guys do? Do you know of any other technical alternatives that would make sense?

Jeff

[Paul Ilechko]

Post by j***@hotmail.com
That part I didn't realize so now I'm wondering what options are
left. Info from the one security-related article that was posted
earlier stated "..You can capture when a user arrives with an expired
session (really a new session) and force them to login again if you
think this is necessary. Keep in mind that doing this undermines
Single Sign On across applications". I don't like the thought about
undermining WebSphere functionality (for which I'm still I'm the
early phases of trying to understand) that was built for a specific
purpose, and I certainly don't want to do it across applications. My
feeling at this point is to make the argument for leaving it as it is
and explaining the reasons and benefits for doing so.
One suggestion from another teammate was to try to invoke IBM's
form-based logout functionality (ibm_security_logout action) somehow
when the user's session expires, but I don't know where to place the
code for doing that. Plus, trying to figure out "here's the user's
session now, but it's not the one they started with (meaning it
*might* have become invalid due to inactivity and not for some other
reason) so log them out" in order to trigger the logout doesn't sit
well with me.

Again, you can force logout - but you log the user out from *all*
applications, not just the one who has an expired session. My suggestion
is that the application should be robust enough to handle session
expiration. It should continue, and should not treat "session expired"
as invalid user, but should re-create the session where possible, or
just force the user to re-start the application flow where nothing else
will work.

[j***@hotmail.com]

<snip/>

Post by Paul Ilechko
My suggestion
is that the application should be robust enough to
handle session
expiration. It should continue, and should not treat
"session expired"
as invalid user, but should re-create the session
where possible,

This is the option I like the most because that's what happens right now. :)

Post by Paul Ilechko
or
just force the user to re-start the application flow
where nothing else
will work.

That might work although it's not something that I want to delve into.

Thanks to everyone for all of the replies and input.

Jeff

[Paul Ilechko]

Post by Ben_
<snip/>

Post by j***@hotmail.com
out). Any ideas on what would cause the sudden change in behavior?
"Before" ? But before what ? What platform did you use "before" ?

We've been using the same platform, but what I meant by "before" is
that it seems like the expiration of our credentials was happening
right when a user's session would expire, and now that doesn't seem
to be the case. I can't say that with absolute certainty b/c it
wasn't something we were testing for, specifically, but it is to the
best of our team's recollection that that was how things were working
until recently.

That's quite possible if you were using SWAM, and the HTTP session
expired before the security session did. It would not happen that way
if you were using LTPA.

[Paul Ilechko]

Post by j***@hotmail.com
I tried to located the LTPAToken cookie but haven't been able to find
C:\Documents and Settings\myName\Cookies C:\Documents and
Settings\myName\Local Settings\Temporary Internet Files
Do you know if the LTPA cookie is created as soon as you authenticate
successfully? Any ideas on how it might be named or where it would
don't know which one might be the right one.

You won't have an LTPA cookie if you're using SWAM. The LTPA model,
which uses a cookie for tracking credentials, provides single signon
across a security domain. SWAM uses the HTTP session for security
tracking and therefore does not provide the same SSO capability. LTPA is
the only production quality security model provided by WAS, SWAM is just
for simple testing.