I'm not sure if you are using machine to mean different physical boxes
or JVM's. The containers on OAS are separate JVMs, but all running on
the same box under the same OAS server.
From what I can tell, the session of the JVMs is not shared server
wide. So when an application authenticates via CAS, and another
application is requested within the same browser session, that new app
could be in another JVM on the same server. When the single sign out
message comes in, it depends which JVM handles that request as to which
application(s) will actually get logged out. Only application that have
session in the JVM will be logged out.
I'm not sure if I could handle this with a custom single sign out
listener and filter or if it's a server setting/tweak. I thought I would
ask the list if anyone had encountered this and how they handled it.
Thanks,
Chad
On 4/8/2010 7:57 PM, Scott Battaglia wrote:
The CAS Client API is flexible enough to support single log out
regardless of machine. However, there is currently no implementation of
single log out that works for multiple machines. I'm willing to work
with people to add that in, but I haven't had time to do it on my own.
Thanks
Scott
On Thu, Apr 8, 2010 at 4:08 PM, Chad Wittrock <[email protected]
<mailto:[email protected]>> wrote:
Anyone have experience with Single Sign Out on OAS running multiple
containers?
Here's what I'm experiencing:
Our development OAS server is only running one container for the
Java apps. That means that every request of that machine grabs from
that same container. That also means that a user accessing multiple
apps on that server within the same browser session pulls from the
same server session. I have a single logout page set up in a common
shared web application (Acl). I test with a sample CAS application
(casTest) to log in and view content. When I click the logout link
in the casTest application it goes to the Acl application which does
it's local logout thing of invalidating the server session and
redirecting to CAS logout. Coming back to the casTest application
after this proves that I am logged out as does the server opmn logs.
In the same manner, going to the casTest application, logging in,
navigating around, then going directly to the CAS logout page (by
typing the logout URL), also logs me out. Thus, Single Sign Out
works on a single container OAS server!
Now our test OAS server that has 4 OC4J containers... Following the
same steps of logging into the casTest application, then clicking
the Logout link which takes me to the Acl application for logout
(session invalidation) and redirect to CAS does not yield the same
results. The reason is that it is a crapshoot if the request to Acl
will grab the server session from the same container that my casTest
application requests were being handled by. I am able to verify this
by watching the logs of each container. So far in all my tests the
casTest application gets session out of one container and the Acl
application gets session out of another container. So when Acl
invalidates the session (for local logout), it invalidates the
session in that container, but not in the container the casTest
requests are being handled in. So logout doesn't even work now.
Now apply all this to Single Sign Out. The Single Sign Out broadcast
is sent to the java server, the problem is, which container receives
it? And is that the same container the user has been operating out
of with their browser session? Again, its a crapshoot. So Single
Sign Out doesn't work when multiple containers are used.
I've done some research into invalidating sessions for all
containers in these situations and am not coming up with anything
yet. This is why I'm sending this email to see if any of you have
any ideas to "solve" this.
Any help/pointers would be greatly appreciated.
Thanks,
Chad
--
------------------------------------------------------------------------------
Chad M Wittrock ([email protected] <mailto:[email protected]>)
Systems Analyst/Web Apps
University of Northern Iowa
(319) 273-7437
--
You are currently subscribed to [email protected]
<mailto:[email protected]> as: [email protected]
<mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
------------------------------------------------------------------------------
Chad M Wittrock ([email protected])
Systems Analyst/Web Apps
University of Northern Iowa
(319) 273-7437
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
