You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by shanmugampl <sh...@india.adventnet.com> on 2003/01/27 09:43:57 UTC
Doubt in Single Sign On !!!
Hi All,
I am using tomcat 4.1.18 and have enabled Single Sign On. I have
two contexts A and B and the files present inside the /jsp directories
of both the contexts are secured. In the global web.xml file i have my
session time out changed to 10 minutes.
With this setup, i login into context A and after some time move to
context B. After moving to context B, i was going through the files
present in context B alone. As i kept on working in context B, the
session of context A got timed out and i was again asked to authenticate
myself.
As i have enabled SSO, shouldn't accessing any one context keep all
the other accessed contexts alive. i.e context A should be alive, even
when not accessed for a long time because context B is accessed frequently.
Hope i am clear. That is how SSO should work, right . Have I
misunderstood anything or have I configured anything wrongly.
Thanks
Shanmugam.PL
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Doubt in Single Sign On !!!
Posted by shanmugampl <sh...@india.adventnet.com>.
Hi,
Can i extend the SingleSignOn class, and specify my class in the
server.xml file. I tried it and got an exception, 'ManagedBean not found
for MySSO'. If i can extend and specify then how should i do it.
Thanks
Shanmugam.PL
shanmugampl wrote:
> Yeah, I accept that SSO is for authentication purposes alone.
>
> My problem is different. Lets us consider the same two contexts A and
> B. I authenticate myself at context A. Once i authenticate, a
> JSESSIONIDSSO is created and sent as a cookie. The StandardSession
> object for context A will be associated to the SSO ID. Now after some
> time if i move on to context B, then the StandardSession Object of
> context B will also be associated with the SSO ID. If my time out
> period is 20 minutes and if i stay in context B alone for more than
> that time, the session of context A will be timed out. When this
> happens, SSO ID will be deregistered and as a result all the
> associated sessions will be invalidated. Therefore at the time of this
> happening, even if i am actively working in context B, i will asked to
> reauthenticate myself.
>
> This is the reason why i thought that SSO should take care of session
> time outs also.
>
> Thanks
> Shanmugam.PL
>
> Craig R. McClanahan wrote:
>
>> On Mon, 27 Jan 2003, shanmugampl wrote:
>>
>>
>>
>>> Date: Mon, 27 Jan 2003 14:13:57 +0530
>>> From: shanmugampl <sh...@india.adventnet.com>
>>> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
>>> shanmugampl@india.adventnet.com
>>> To: tomcat-user@jakarta.apache.org
>>> Subject: Doubt in Single Sign On !!!
>>>
>>> Hi All,
>>>
>>> I am using tomcat 4.1.18 and have enabled Single Sign On. I have
>>> two contexts A and B and the files present inside the /jsp directories
>>> of both the contexts are secured. In the global web.xml file i have my
>>> session time out changed to 10 minutes.
>>>
>>> With this setup, i login into context A and after some time move to
>>> context B. After moving to context B, i was going through the files
>>> present in context B alone. As i kept on working in context B, the
>>> session of context A got timed out and i was again asked to
>>> authenticate
>>> myself.
>>>
>>> As i have enabled SSO, shouldn't accessing any one context keep all
>>> the other accessed contexts alive. i.e context A should be alive, even
>>> when not accessed for a long time because context B is accessed
>>> frequently.
>>>
>>> Hope i am clear. That is how SSO should work, right . Have I
>>> misunderstood anything or have I configured anything wrongly.
>>>
>>>
>>
>>
>> SSO has nothing at all to do with session timeouts. It only involves
>> authentication.
>>
>>
>>
>>> Thanks
>>> Shanmugam.PL
>>>
>>>
>>
>>
>> Craig
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>
>
Re: Doubt in Single Sign On !!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 29 Jan 2003, shanmugampl wrote:
> Date: Wed, 29 Jan 2003 10:53:41 +0530
> From: shanmugampl <sh...@india.adventnet.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
> shanmugampl@india.adventnet.com
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Doubt in Single Sign On !!!
>
> Will this be supported in the future releases of Tomcat
The best way to make sure that happens is to submit an enhancement
request, plus a patch that enables the feature you want, to:
http://nagoya.apache.org/bugzilla/
That way, a Tomcat committer can at least evaluate what you think you
want, and look at a solution (prepared by you) that actually works in the
real world.
A much less effective way is to just submit an enhancement request without
a patch. Then, you are depending on the interest of some Tomcat committer
in caring about this particular issue, then crafting and testing a
solution that may or may not actually meet *your* requirements.
Using open source software, and wanting enhancements, means that *you*
need to take more responsibility if you really care about something.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Doubt in Single Sign On !!!
Posted by shanmugampl <sh...@india.adventnet.com>.
Will this be supported in the future releases of Tomcat
Craig R. McClanahan wrote:
>On Tue, 28 Jan 2003, Will Hartung wrote:
>
>
>
>>Date: Tue, 28 Jan 2003 13:32:46 -0800
>>From: Will Hartung <wi...@msoft.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>To: Tomcat Users List <to...@jakarta.apache.org>
>>Subject: Re: Doubt in Single Sign On !!!
>>
>>
>>
>>>From: "Craig R. McClanahan" <cr...@apache.org>
>>>Sent: Tuesday, January 28, 2003 1:04 PM
>>>Subject: Re: Doubt in Single Sign On !!!
>>>
>>>
>>
>>
>>>The reason for this design is security.
>>>
>>>Consider a portal-type application like My Yahoo, which implements their
>>>version of single sign on (you don't have to log in to mail, then to
>>>games, then to ...). I browse around between the apps, and decide to log
>>>out. Should the effect of this logout be global? I would suggest that it
>>>should -- you don't want to be in an Internet cafe and log out of one
>>>Yahoo app, but forget that you haven't logged out of all the rest.
>>>
>>>
>>All well and good, but it seems to me that the problem that is being
>>described here is that the sessions of each application have their own
>>distinct timers, rather than a global timer for the single-sign-on session.
>>
>>
>>
>
>True ... there is no such thing as a cross-application session defined in
>the servlet spec.
>
>
>
>>Using Yahoo as an example, and, say, a 15 minute timeout, it would a fair
>>expectation that if I log in to Yahoo, go read my mail, and then go and play
>>Yahoo Cribbage for 30 minutes, then I would expect at the end of my last
>>game to be able to pop back over to Yahoo Mail and still be authenticated.
>>
>>What is being described here sounds as if in this contrived example that the
>>Yahoo Mail will time out in 15 minutes because it wasn't accessed, even
>>though I was still "logged in" and active over on Yahoo Games.
>>
>>
>>
>>>In the servlet world, session timeout logs you out (if you're using form
>>>based login). Therefore, it should be (and is) treated the same as an
>>>explicit logout by the user.
>>>
>>>
>>Of course. The difficulty here is that the actual application sessions
>>perhaps needs some kind of tie to the overall master single-sign on session,
>>and not timeout until the SSO session times out.
>>
>>
>>
>
>You're outside the bounds of the servlet spec when you talk about this,
>but nothing stops a container from providing something like it.
>
>
>
>>Regards,
>>
>>Will Hartung
>>(willh@msoft.com)
>>
>>
>>
>
>Craig
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
Re: Doubt in Single Sign On !!!
Posted by shanmugampl <sh...@india.adventnet.com>.
I agree with Will completely . I have found a way to solve this issue
and in that process have one more doubt.
The invoke method of SingleSignOn is getting called when request for a
resource is placed. The details of all the sessions that are currently
associated is available inside the method. To solve my issue, what i
have done is that i have retrieved all the Session objects and called
the access() method so that the LastAccessed time gets updated for all
the sessions when a request is placed for a particular context. This i
have done it by extending the SingleSignOn and overriding the invoke
method. Now if i specify my class in the server.xml i am getting an
exception saying that Managed Bean not found with "MyClasssName". How
should i go about specifying my class in the server.xml instead of
SingleSignOn.
Thanks
Shanmugam
Will Hartung wrote:
>>From: "Craig R. McClanahan" <cr...@apache.org>
>>Sent: Tuesday, January 28, 2003 2:01 PM
>>Subject: Re: Doubt in Single Sign On !!!
>>
>>
>
>
>
>
>>True ... there is no such thing as a cross-application session defined in
>>the servlet spec.
>>
>>You're outside the bounds of the servlet spec when you talk about this,
>>but nothing stops a container from providing something like it.
>>
>>
>
>Yes, for example, the Tomcat Servlet Container (tm reg. us. pat. off.) has a
>Single Sign On facility that's outside of the Servlet Spec, but it doesn't
>behave as a consistent time out across all the webapps its supporting. :-)
>
>Regards,
>
>Will Hartung
>(willh@msoft.com)
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
Re: Doubt in Single Sign On !!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 28 Jan 2003, Will Hartung wrote:
> Date: Tue, 28 Jan 2003 16:49:09 -0800
> From: Will Hartung <wi...@msoft.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Doubt in Single Sign On !!!
>
> > From: "Craig R. McClanahan" <cr...@apache.org>
> > Sent: Tuesday, January 28, 2003 2:01 PM
> > Subject: Re: Doubt in Single Sign On !!!
>
>
> > True ... there is no such thing as a cross-application session defined in
> > the servlet spec.
> >
> > You're outside the bounds of the servlet spec when you talk about this,
> > but nothing stops a container from providing something like it.
>
> Yes, for example, the Tomcat Servlet Container (tm reg. us. pat. off.) has a
> Single Sign On facility that's outside of the Servlet Spec, but it doesn't
> behave as a consistent time out across all the webapps its supporting. :-)
>
Actually, SSO is *not* outside the bounds of the spec :-). See Section
SRV.12.6 of the Servlet 2.3 Specification, and Tomcat's implementation
complies with the requrements there. What is not defined is where
the boundaries of a "security policy domain" are with respect to SSO --
Tomcat's choice to implement this at the virtual host level is entirely
legitimate, as would an SSO implementation that was based on Project
Liberty <http://www.libertyalliance.org/> that covered multiple web apps
on multiple servers (not even necessarily all Java based).
However, Section 12.6 only talks about propogating security identities; it
says nothing about updating the last access time of sessions in other web
apps so that they don't time out. Technically, that would not be hard to
accomplish (modify the existing SSO valve to call access() on the internal
StandardSession object of each related session) -- but you wont' be able
to claim that such behavior is "required".
> Regards,
>
> Will Hartung
> (willh@msoft.com)
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Why do I need to set classpath for IBM JDK, but not Sun's?
Posted by Brandon Cruz <bc...@norvax.com>.
Does anyone know why I need to set a system classpath when using the IBM
JDK, but have no problems if I don't set a classpath when using the Sun
JDK's?
Does tomcat add jar files from the sun package based on file name?
For example, I see that the java/lang package is in rt.jar in sun's package,
but in core.jar in IBM's.
Brandon Cruz
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Doubt in Single Sign On !!!
Posted by Will Hartung <wi...@msoft.com>.
> From: "Craig R. McClanahan" <cr...@apache.org>
> Sent: Tuesday, January 28, 2003 2:01 PM
> Subject: Re: Doubt in Single Sign On !!!
> True ... there is no such thing as a cross-application session defined in
> the servlet spec.
>
> You're outside the bounds of the servlet spec when you talk about this,
> but nothing stops a container from providing something like it.
Yes, for example, the Tomcat Servlet Container (tm reg. us. pat. off.) has a
Single Sign On facility that's outside of the Servlet Spec, but it doesn't
behave as a consistent time out across all the webapps its supporting. :-)
Regards,
Will Hartung
(willh@msoft.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Doubt in Single Sign On !!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 28 Jan 2003, Will Hartung wrote:
> Date: Tue, 28 Jan 2003 13:32:46 -0800
> From: Will Hartung <wi...@msoft.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Doubt in Single Sign On !!!
>
> > From: "Craig R. McClanahan" <cr...@apache.org>
> > Sent: Tuesday, January 28, 2003 1:04 PM
> > Subject: Re: Doubt in Single Sign On !!!
>
>
> > The reason for this design is security.
> >
> > Consider a portal-type application like My Yahoo, which implements their
> > version of single sign on (you don't have to log in to mail, then to
> > games, then to ...). I browse around between the apps, and decide to log
> > out. Should the effect of this logout be global? I would suggest that it
> > should -- you don't want to be in an Internet cafe and log out of one
> > Yahoo app, but forget that you haven't logged out of all the rest.
>
> All well and good, but it seems to me that the problem that is being
> described here is that the sessions of each application have their own
> distinct timers, rather than a global timer for the single-sign-on session.
>
True ... there is no such thing as a cross-application session defined in
the servlet spec.
> Using Yahoo as an example, and, say, a 15 minute timeout, it would a fair
> expectation that if I log in to Yahoo, go read my mail, and then go and play
> Yahoo Cribbage for 30 minutes, then I would expect at the end of my last
> game to be able to pop back over to Yahoo Mail and still be authenticated.
>
> What is being described here sounds as if in this contrived example that the
> Yahoo Mail will time out in 15 minutes because it wasn't accessed, even
> though I was still "logged in" and active over on Yahoo Games.
>
> > In the servlet world, session timeout logs you out (if you're using form
> > based login). Therefore, it should be (and is) treated the same as an
> > explicit logout by the user.
>
> Of course. The difficulty here is that the actual application sessions
> perhaps needs some kind of tie to the overall master single-sign on session,
> and not timeout until the SSO session times out.
>
You're outside the bounds of the servlet spec when you talk about this,
but nothing stops a container from providing something like it.
> Regards,
>
> Will Hartung
> (willh@msoft.com)
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Doubt in Single Sign On !!!
Posted by Will Hartung <wi...@msoft.com>.
> From: "Craig R. McClanahan" <cr...@apache.org>
> Sent: Tuesday, January 28, 2003 1:04 PM
> Subject: Re: Doubt in Single Sign On !!!
> The reason for this design is security.
>
> Consider a portal-type application like My Yahoo, which implements their
> version of single sign on (you don't have to log in to mail, then to
> games, then to ...). I browse around between the apps, and decide to log
> out. Should the effect of this logout be global? I would suggest that it
> should -- you don't want to be in an Internet cafe and log out of one
> Yahoo app, but forget that you haven't logged out of all the rest.
All well and good, but it seems to me that the problem that is being
described here is that the sessions of each application have their own
distinct timers, rather than a global timer for the single-sign-on session.
Using Yahoo as an example, and, say, a 15 minute timeout, it would a fair
expectation that if I log in to Yahoo, go read my mail, and then go and play
Yahoo Cribbage for 30 minutes, then I would expect at the end of my last
game to be able to pop back over to Yahoo Mail and still be authenticated.
What is being described here sounds as if in this contrived example that the
Yahoo Mail will time out in 15 minutes because it wasn't accessed, even
though I was still "logged in" and active over on Yahoo Games.
> In the servlet world, session timeout logs you out (if you're using form
> based login). Therefore, it should be (and is) treated the same as an
> explicit logout by the user.
Of course. The difficulty here is that the actual application sessions
perhaps needs some kind of tie to the overall master single-sign on session,
and not timeout until the SSO session times out.
Regards,
Will Hartung
(willh@msoft.com)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Doubt in Single Sign On !!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 28 Jan 2003, shanmugampl wrote:
> Date: Tue, 28 Jan 2003 10:46:13 +0530
> From: shanmugampl <sh...@india.adventnet.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
> shanmugampl@india.adventnet.com
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Doubt in Single Sign On !!!
>
> Yeah, I accept that SSO is for authentication purposes alone.
>
> My problem is different. Lets us consider the same two contexts A and B.
> I authenticate myself at context A. Once i authenticate, a JSESSIONIDSSO
> is created and sent as a cookie. The StandardSession object for context
> A will be associated to the SSO ID. Now after some time if i move on to
> context B, then the StandardSession Object of context B will also be
> associated with the SSO ID. If my time out period is 20 minutes and if i
> stay in context B alone for more than that time, the session of context
> A will be timed out. When this happens, SSO ID will be deregistered and
> as a result all the associated sessions will be invalidated. Therefore
> at the time of this happening, even if i am actively working in context
> B, i will asked to reauthenticate myself.
The reason for this design is security.
Consider a portal-type application like My Yahoo, which implements their
version of single sign on (you don't have to log in to mail, then to
games, then to ...). I browse around between the apps, and decide to log
out. Should the effect of this logout be global? I would suggest that it
should -- you don't want to be in an Internet cafe and log out of one
Yahoo app, but forget that you haven't logged out of all the rest.
In the servlet world, session timeout logs you out (if you're using form
based login). Therefore, it should be (and is) treated the same as an
explicit logout by the user.
>
> This is the reason why i thought that SSO should take care of session
> time outs also.
If session timeouts are biting you, set longer session timeouts.
>
> Thanks
> Shanmugam.PL
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Doubt in Single Sign On !!!
Posted by shanmugampl <sh...@india.adventnet.com>.
Yeah, I accept that SSO is for authentication purposes alone.
My problem is different. Lets us consider the same two contexts A and B.
I authenticate myself at context A. Once i authenticate, a JSESSIONIDSSO
is created and sent as a cookie. The StandardSession object for context
A will be associated to the SSO ID. Now after some time if i move on to
context B, then the StandardSession Object of context B will also be
associated with the SSO ID. If my time out period is 20 minutes and if i
stay in context B alone for more than that time, the session of context
A will be timed out. When this happens, SSO ID will be deregistered and
as a result all the associated sessions will be invalidated. Therefore
at the time of this happening, even if i am actively working in context
B, i will asked to reauthenticate myself.
This is the reason why i thought that SSO should take care of session
time outs also.
Thanks
Shanmugam.PL
Craig R. McClanahan wrote:
>On Mon, 27 Jan 2003, shanmugampl wrote:
>
>
>
>>Date: Mon, 27 Jan 2003 14:13:57 +0530
>>From: shanmugampl <sh...@india.adventnet.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
>> shanmugampl@india.adventnet.com
>>To: tomcat-user@jakarta.apache.org
>>Subject: Doubt in Single Sign On !!!
>>
>> Hi All,
>>
>> I am using tomcat 4.1.18 and have enabled Single Sign On. I have
>>two contexts A and B and the files present inside the /jsp directories
>>of both the contexts are secured. In the global web.xml file i have my
>>session time out changed to 10 minutes.
>>
>> With this setup, i login into context A and after some time move to
>>context B. After moving to context B, i was going through the files
>>present in context B alone. As i kept on working in context B, the
>>session of context A got timed out and i was again asked to authenticate
>>myself.
>>
>> As i have enabled SSO, shouldn't accessing any one context keep all
>>the other accessed contexts alive. i.e context A should be alive, even
>>when not accessed for a long time because context B is accessed frequently.
>>
>> Hope i am clear. That is how SSO should work, right . Have I
>>misunderstood anything or have I configured anything wrongly.
>>
>>
>>
>
>SSO has nothing at all to do with session timeouts. It only involves
>authentication.
>
>
>
>>Thanks
>>Shanmugam.PL
>>
>>
>>
>
>Craig
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
Re: Doubt in Single Sign On !!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 27 Jan 2003, shanmugampl wrote:
> Date: Mon, 27 Jan 2003 14:13:57 +0530
> From: shanmugampl <sh...@india.adventnet.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
> shanmugampl@india.adventnet.com
> To: tomcat-user@jakarta.apache.org
> Subject: Doubt in Single Sign On !!!
>
> Hi All,
>
> I am using tomcat 4.1.18 and have enabled Single Sign On. I have
> two contexts A and B and the files present inside the /jsp directories
> of both the contexts are secured. In the global web.xml file i have my
> session time out changed to 10 minutes.
>
> With this setup, i login into context A and after some time move to
> context B. After moving to context B, i was going through the files
> present in context B alone. As i kept on working in context B, the
> session of context A got timed out and i was again asked to authenticate
> myself.
>
> As i have enabled SSO, shouldn't accessing any one context keep all
> the other accessed contexts alive. i.e context A should be alive, even
> when not accessed for a long time because context B is accessed frequently.
>
> Hope i am clear. That is how SSO should work, right . Have I
> misunderstood anything or have I configured anything wrongly.
>
SSO has nothing at all to do with session timeouts. It only involves
authentication.
> Thanks
> Shanmugam.PL
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>