User logout from admin console when ltpa token expired
ting...@us.ibm.com
After login to WebSphere admin console, refreshing the page every 2 minutes, but the login page shown after login about 5 minutes.
The trace file from WebSphere 6.0.2.11 shows:
[10/8/07 11:13:32:023 EDT] 00000033 WSCredentialT 3 WSCredential has expired, returning false.
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < validate: LTPA token validation failed Exit
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < handleSSO: (null) Exit
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica 3 Form based login: No or Bad ltpa cookie
I thought the user should be reauthenticated automatically and the login page should never be displayed if the page was refreshed periodically.
Could you somebody explain why it happens, is it a bug? The same thing happens on WebSphere 6.0.2.21 also.
Thanks,
Paul Ilechko
This is how it's supposed to work. If the LTPA token has expired, you
need to re-authenticate. You need to come up with a more reasonable
timeout value - it's an absolute timeout, and has no relation to user
activity like the Session timeout does.
ting...@us.ibm.com
It doesn't match the normal user experience that the browser always shows the page when refreshed by user if the refresh is before the session time-out. Should the websphere server automatically reauthenticate the user when the ltpa token timeout? I also noticed this information in the trace file.
[10/8/07 11:10:59:613 EDT] 00000033 WSCredentialT 3 WSCredential has expired, returning false.
[10/8/07 11:10:59:613 EDT] 00000033 distContextMa 3 Is server subject valid? false
[10/8/07 11:10:59:613 EDT] 00000033 distContextMa 3 Server Subject expired, refreshing...
[10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Expiration passed into cloned token: 1191856350122
[10/8/07 11:10:59:613 EDT] 00000033 LTPAToken > new LTPAToken from clone Entry
[10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Refreshing expiration of token.
[10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Expiration set to: Mon Oct 08 11:15:59 EDT 2007
[10/8/07 11:10:59:613 EDT] 00000033 LTPAToken < new LTPAToken from clone Exit
[10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Expiration passed into cloned token: 1191856350393
[10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke > AuthzPropToken from userData Entry
[10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Refreshing expiration of token.
[10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Expiration set to: Mon Oct 08 11:15:59 EDT 2007
[10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke < AuthzPropToken from userData Exit
Does it show the LTPA token was re-generated at that time? Why did it be different 2 minutes later, that shows this trace information:
[10/8/07 11:13:32:023 EDT] 00000033 WSCredentialT 3 WSCredential has expired, returning false.
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < validate: LTPA token validation failed Exit
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < handleSSO: (null) Exit
[10/8/07 11:13:32:023 EDT] 00000033 distContextMa > getDefaultRealmName() Entry
[10/8/07 11:13:32:023 EDT] 00000033 distContextMa < getDefaultRealmName() -> IBM-FE918FF7B3B Exit
[10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica > handleCustomLogin Entry
If it is design as so, how can I keep the user from logout except for giving a very large LTPA token time-out value.
Thanks lot!
Paul Ilechko
> Thanks for the response!
> It doesn't match the normal user experience that the browser always shows the page when refreshed by user if the refresh is before the session time-out. Should the websphere server automatically reauthenticate the user when the ltpa token timeout? I also noticed this information in the trace file.
The LTPA timeout has nothing to do with the Session Timeout.
> [10/8/07 11:10:59:613 EDT] 00000033 WSCredentialT 3 WSCredential has expired, returning false.
> [10/8/07 11:10:59:613 EDT] 00000033 distContextMa 3 Is server subject valid? false
> [10/8/07 11:10:59:613 EDT] 00000033 distContextMa 3 Server Subject expired, refreshing...
> [10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Expiration passed into cloned token: 1191856350122
> [10/8/07 11:10:59:613 EDT] 00000033 LTPAToken > new LTPAToken from clone Entry
> [10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Refreshing expiration of token.
> [10/8/07 11:10:59:613 EDT] 00000033 LTPAToken 3 Expiration set to: Mon Oct 08 11:15:59 EDT 2007
> [10/8/07 11:10:59:613 EDT] 00000033 LTPAToken < new LTPAToken from clone Exit
> [10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Expiration passed into cloned token: 1191856350393
> [10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke > AuthzPropToken from userData Entry
> [10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Refreshing expiration of token.
> [10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke 3 Expiration set to: Mon Oct 08 11:15:59 EDT 2007
> [10/8/07 11:10:59:623 EDT] 00000033 AuthzPropToke < AuthzPropToken from userData Exit
>
> Does it show the LTPA token was re-generated at that time? Why did it be different 2 minutes later, that shows this trace information:
Probably the user was still in the security cache the first time.
> [10/8/07 11:13:32:023 EDT] 00000033 WSCredentialT 3 WSCredential has expired, returning false.
> [10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < validate: LTPA token validation failed Exit
> [10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica < handleSSO: (null) Exit
> [10/8/07 11:13:32:023 EDT] 00000033 distContextMa > getDefaultRealmName() Entry
> [10/8/07 11:13:32:023 EDT] 00000033 distContextMa < getDefaultRealmName() -> IBM-FE918FF7B3B Exit
> [10/8/07 11:13:32:023 EDT] 00000033 WebAuthentica > handleCustomLogin Entry
>
> If it is design as so, how can I keep the user from logout except for giving a very large LTPA token time-out value.
>
> Thanks lot!
You need to give a large enough timeout not to annoy your users too
much, but not so large that it is a security hazard. I can't tell you
what that is, it depends on the application. I think two hours is the
default value.
ting...@us.ibm.com
I did some tests, but the results are not consistent. So I am not sure what is exptected.
Thanks for the reponses!
Paul Ilechko
I'm not sure exactly what the symptoms will be, but in this case your
client code should re-login transparently to the end user.
Paul Ilechko
> Hi Paul,
> I also read your post in the thread http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=266&thread=179273&cat=9
> Could you please clearify when you said "your client code should re-login transparently to the end user." Do you mean the ejb client client code should do re-authentication or the EJB container, which is websphre code should do the re-authentication.
> Thanks,
> Ting
For an EJB client, authentication happens at the client. You can find
examples of this in the WAS infocenter.
ting...@us.ibm.com
Ben_
> but not so large that it is a security hazard. I can't tell you what that
> is, it depends on the application. I think two hours is the default value.
Actually, I fail to see the rationale for an absolute timeout.
I can envision it has to do with distributed environments.
But why can't the token be made to have a relative time out ?
Absolute time out leads to strange situations: when the token time out is 2
hours and you've been logged in for 1:55 without doing serious work and then
begin something serious taking 30 minutes, it's more than frustrating to
have to authenticate again just after 5 minutes. People don't understand why
they are "interrupted" in their work.
Why isn't it possible (or desirable ?) for the security layer to modify the
"expiry" field in the token (I suppose it has one -- otherwise I don't
understand how the expiry is determined...). As the keys are shared between
servers in the SSO domain, it could modify and re-encrypt.
Thanks to shed light... :-)
Paul Ilechko
>> You need to give a large enough timeout not to annoy your users too
>> much, but not so large that it is a security hazard. I can't tell you
>> what that is, it depends on the application. I think two hours is the
>> default value.
>
> Actually, I fail to see the rationale for an absolute timeout.
Because the longer a security token lives, the less secure it is. A
relative timeout never actually has to expire, so someone who steals one
can use it indefinitely. It's about limiting risk.
>
> I can envision it has to do with distributed environments.
>
> But why can't the token be made to have a relative time out ?
>
> Absolute time out leads to strange situations: when the token time out
> is 2 hours and you've been logged in for 1:55 without doing serious work
> and then begin something serious taking 30 minutes, it's more than
> frustrating to have to authenticate again just after 5 minutes. People
> don't understand why they are "interrupted" in their work.
There are other options. I you use a security proxy like WebSeal (TAM),
it will silently re-authenticate to WAS through the TAI interface.
Ben_
>> Actually, I fail to see the rationale for an absolute timeout.
>
> Because the longer a security token lives, the less secure it is. A
> relative timeout never actually has to expire, so someone who steals one
> can use it indefinitely. It's about limiting risk.
Fully agreed that token must change over time to avoid sort of replay
attacks.
Do I understand it correctly that in a WAS SSO domain, any of the WAS can
give an authentication token valid for any other WAS in the domain ?
<ASCII ART>
----> WAS 1
/
IE --(token)--
\
----> WAS 2
</ASCII ART>
If so, I wonder why the token cannot have a relative duration and be
prolonged by a member of the SSO domain when there is activity with this
token.
>>
>> I can envision it has to do with distributed environments.
>>
>> But why can't the token be made to have a relative time out ?
>>
>> Absolute time out leads to strange situations: when the token time out is
>> 2 hours and you've been logged in for 1:55 without doing serious work and
>> then begin something serious taking 30 minutes, it's more than
>> frustrating to have to authenticate again just after 5 minutes. People
>> don't understand why they are "interrupted" in their work.
>
>
> There are other options. I you use a security proxy like WebSeal (TAM), it
> will silently re-authenticate to WAS through the TAI interface.
I was keeping TAM out of the picture for now, but if you enter it...
Does it manage the expiration of its token with the client differently than
a WAS SSO domain without it ?
Paul Ilechko
>
> Fully agreed that token must change over time to avoid sort of replay
> attacks.
>
> Do I understand it correctly that in a WAS SSO domain, any of the WAS
> can give an authentication token valid for any other WAS in the domain ?
>
> <ASCII ART>
> ----> WAS 1
> /
> IE --(token)--
> \
> ----> WAS 2
> </ASCII ART>
>
> If so, I wonder why the token cannot have a relative duration and be
> prolonged by a member of the SSO domain when there is activity with this
> token.
>
Well, for the same reason that I already said - it's a huge risk to have
an indefinite lifetime token. The fact that there is more than one
appserver or application doesn't change that. You login to any appserver
in the domain, you get a token good for a certain period of time
(configurable). At the end of that time, the token expires, you need to
get a new one. Doesn't matter which app your are currently working on,
all your access to the domain is expired.
> I was keeping TAM out of the picture for now, but if you enter it...
>
> Does it manage the expiration of its token with the client differently
> than a WAS SSO domain without it ?
Yes - at least in theory there is no cookie, therefore nothing to steal.
It's all handled by using caching on the WebSeal server. In practice,
that depends on how you are doing failover ...
Another way to avoid the re-login issue is to use SPNEGO from the desktop.
Paul Ilechko
>> it's a huge risk to have an indefinite lifetime token.
>
> new token B.
>
> But that won't work, because if valid user activity extends the life
> time of the token, activity by a devil stealing token A or B can as well...
>
> And considering the token is for SSO, when stolen the devil has access
> to all applications in the domain. This is indeed quite dramatic...
>
> So, unless you have trustworthy transparent authentication mechanism,
> you need to be presented a page to re-enter your credentials.
>
> I think I'm getting the point now, thx. :-)
>
>>> I was keeping TAM out of the picture for now, but if you enter it...
>>>
>>> Does it manage the expiration of its token with the client
>>> differently than a WAS SSO domain without it ?
>>
>> Yes - at least in theory there is no cookie, therefore nothing to
>> steal. It's all handled by using caching on the WebSeal server.
>
> manage authentication is when it relies on mechanisms between the
> browser and the web server to authenticate each connection (much like
> NTLM between IE and IIS) ?
From the WebSeal info center:
WebSEAL maintains the specific client identity and session information
in a session cache. Each session cache entry is indexed by a session key
(the WebSEAL session ID).
The following supported data types can provide the session key used by
WebSEAL to maintain session state with a client:
* SSL session ID (defined by the SSL protocol)
* Server-specific session cookie
* HTTP header data
* IP address
When WebSEAL examines a client request, it searches for the session key
in the order specified in this list.
Ben_
I was thinking to sort of prolong token A by in fact replacing it by a new
token B.
But that won't work, because if valid user activity extends the life time of
the token, activity by a devil stealing token A or B can as well...
And considering the token is for SSO, when stolen the devil has access to
all applications in the domain. This is indeed quite dramatic...
So, unless you have trustworthy transparent authentication mechanism, you
need to be presented a page to re-enter your credentials.
I think I'm getting the point now, thx. :-)
>> I was keeping TAM out of the picture for now, but if you enter it...
>>
>> Does it manage the expiration of its token with the client differently
>> than a WAS SSO domain without it ?
>
> Yes - at least in theory there is no cookie, therefore nothing to steal.
> It's all handled by using caching on the WebSeal server.
I suppose that the scenario where WebSeal doesn't need a cookie to manage
Ben_
> WebSEAL to maintain session state with a client:
> * SSL session ID (defined by the SSL protocol)
> * Server-specific session cookie
> * HTTP header data
> * IP address
OK, now I understand the "at least in theory there is no cookie". Thx.
ting...@us.ibm.com
I am reading one of you artical, http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html. It is a very good artical.
When you said "authentication happens at the client", did you mean the login module in the client? You didn't mean the ejb client code or the user has to login explicitly again when the lpta token timeout, did you?
Thanks!
Paul Ilechko
If you have a java client, calling a remote EJB, then the login happens
in the client application code. There is no login module at the client,
login modules are on the server. So yes, I'm talking about java code in
the application client needing to catch the error and reauthenticate.