On 02.12.2015 16:55, Christopher Schultz wrote:
Jerry,
On 12/1/15 2:39 PM, Jerry Malcolm wrote:
On 12/1/2015 12:17 PM, Jose María Zaragoza wrote:
ts automatically resets the session timer.
Only if the request goes to the same application.
You can create a HttpSessionListener who saves some info on a shared
store when session is expired.
Anothe REST service could check the status of the session when is
requested by your page
Jose,
I understand the listener and storing the state in common storage. But
I'm confused on your statement above about the same application. I have
several web apps running on the same host instance. They all share a
common login using SingleSignOn.
Each application has a distinct HttpSession object. The SingleSignOn
cookie allows each application to re-authenticate using the SSO
information, so you get a new HttpSession if your old one times out.
If I hit any of the apps it resets the timer.
I don't think hitting app A will reset the session timeout of app B's
session. (Or maybe it does, but I didn't think that's how SSO worked in
Tomcat. Unfortunately, the SSO documentation[1] doesn't actually say
exactly how all this works.)
Do they all have separate sessions but share a common login state?
Yes.
What is the relationship between "logged in" and separate webapp
sessions that come and go independently. What I really care about is
whether the authenticator is going to bounce the request to a login page
or not. It still seems like calling any app is going to reset the
logged-in timer if I'm using single sign-on (?).
The authenticator is not going to sent you to a login page for any
application unless either of these events occurs:
(a) You explicitly log-out from one of the applications. This will
terminate the SSO cookie and revoke your logins on all associated
applications.
(b) Your SSO cookie (or server-based info) expires. Then you will be
asked to authenticate again.
If you are using SSO, this adds a bit of mystery to the situation, since
what you really want to find out is whether the /SSO token/ is still
valid. The validity of any of the various individual-application session
identifiers is irrelevant, since if the SSO token is valid, you will be
automatically re-authenticated to the individual applications.
I think you may have to re-think how you detect the expiration of your
users' logins.
Hi.
I am sorry to barge in this discussion, which I have been loosely following over several
days, but I have to say that at least based on the documentation at
http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Single_Sign_On_Valve
and
http://tomcat.apache.org/tomcat-8.0-doc/config/host.html#Single_Sign_On
, I still do not understand what the problem is, that Jerry is trying to solve.
In his original post, Jerry said
"But basically, I want to know that the session is no longer valid and force the user back
to the login page."
And he later mentioned that he was using the SSO Valve, and container-based Form
authentication for the webapps.
But as far as I understand, that is the way in which this works :
- as soon as the user (initially) accesses any of the protected applications, he/she gets
a login page and has to login. Thereafter, he/she gets access to the requested
application, which creates an "application session", in which the logged-in state is recorded.
- because of the SSO Valve, some information is also stored separately, regarding the user
authentication
- now if the user accesses another protected application, the container - which would
normally send back a login form - notices that there is stored SSO authentication
information, and automatically authenticates the user for this second application.
Which also creates a separate "application session" stored on the server.
- and so on...
- at some point in the future, any one of these stored application sessions becomes
invalid (either by something actively invalidating the session, or by a session timeout).
At this point - if I believe the documentation - the container immediately invalidates all
the other application sessions and whatever SSO authentication had been saved, so that if
the user subsequently accesses any other (or the same) application, they get a login page
again.
And is that not precisely what Jerry wanted to achieve in the first place ?
Or am I missing/misunderstanding something ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
