You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2006/10/17 17:52:53 UTC
DO NOT REPLY [Bug 40775] New: - Single-sign on session invalidation not working as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40775>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40775
Summary: Single-sign on session invalidation not working as
expected
Product: Tomcat 5
Version: 5.5.17
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: mark.oliveira@gmail.com
After enabling the single sign-on valve, I noticed unexpected logout behavior.
Here are steps to reproduce:
1. Using form auth, log into webapp1 (by attempting to access a protected
resource that does not exist)
2. Attempt to access a protected resource in webapp2 is granted (meaning you
are logged into 2 by logging into 1 as we expect).
3. Invalidating the session from webapp2 does not log you out.
It appears that you are able to sign-on and be authorized by other webapps
without accessing an existing protected resource but you will not be able to
logout from those webapps. I can provide simple sample webapps to demonstrate
this behavior. This was discovered in an embedded Tomcat in JBoss and they
explained the issue as following:
"What you're seeing is due to a subtlety in your test combining with a subtlety
in how Tomcat SSO invalidation works.
The reason you can invalidate an SSO and not just a single session by calling
session.invalidate() is because Tomcat provides a reference to the session to
the SSO valve. The valve registers as a listener on the session and thus gets
a callback when you call session.invalidate(). It then uses that callback to
invalidate the SSO.
The problem is the way Tomcat provides the reference to the session to the SSO
valve. This only happens if you access a protected resource. If you look at
the steps in your test, you'll notice you never access a protected resource in
testapp2. Thus the SSO valve doesn't know about your testapp2 session. When
you invalidate the session, the SSO doesn't get invalidated. "
I expect that if you are considered logged into a webapp you should also be
able to log out from that same web app. Please let me know your thoughts.
Thanks
Mark
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40775] - Single-sign on session invalidation not working as expected
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40775>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40775
markt@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From markt@apache.org 2006-11-12 15:57 -------
I have tested the following sequence of events using the latest source from SVN.
- set up 2 webapps, A & B, both using FORM authentication
- enabled SSO
- request non-existant, protected resource from A -> login.jsp
- enter user/pwd & submit -> 404
- request existing, protected resource from B -> resource shown, no login prompt
- logout of B
- request existing, protected resource from A -> login.jsp
As I understand it, in the last step you saw the protected resource.
I am going to resolve this as works for me. If you still see this issue please
run you test cases with the latest stable version (5.5.20 at the the time of
writing this comment). If you still see the same problem, please re-open this
issue, attach you test case and I will investigate further.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40775] - Single-sign on session invalidation not working as expected
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40775>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40775
pr@objektpark.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |NEEDINFO
------- Additional Comments From pr@objektpark.de 2008-01-07 00:57 -------
I think, that a app session only must register to SSO cache as user really login!
The problem is: Why you got a RemoteUser and UserPrincipal at your testapp2, without login?
Currently SingleSignOn valve set this information without a auth check. That looks strange for me!
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40775] - Single-sign on session invalidation not working as expected
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40775>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40775
------- Additional Comments From mark.oliveira@gmail.com 2007-02-12 07:09 -------
Created an attachment (id=19575)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=19575&action=view)
Contains test wars and a copy of server.xml containing the SSO valve
declaration.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40775] - Single-sign on session invalidation not working as expected
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40775>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40775
mark.oliveira@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
Version|5.5.17 |5.5.20
------- Additional Comments From mark.oliveira@gmail.com 2007-02-12 07:11 -------
Hi,
We have recently upgraded to Tomcat 5.5.20 so I have revisited this bug and
noticed an error in my test case. The following steps should be used to
reproduce this behavior:
1. Using form auth, log into webapp1 (by attempting to access a protected
resource that does not exist)
2. Access a NONprotected resource in webapp2 (in my test I use a call to
request.getRemoteUser() in this resource to verify that I am logged in).
3. Invalidating the session from webapp2 does not log you out.
As you can see, webapp2 knows about the remoteUser and if you were to attempt to
access a protected resource access would be granted. Considering this behavior
it appears that you are in fact logged in to webapp2 by logging into webapp1 (as
expected). The problem here is that if you are logged in then you should also
be able to log out, but this is not possible until you actually access a
protected resource. I have verified that this behavior is present in 5.5.20 and
have provided test wars. Please have a look.
Thanks,
Mark
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org