You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Dominik Drzewiecki <dr...@post.pl> on 2005/08/03 11:59:36 UTC
Standart Sessions included in the SSO Session expire
I have a conceptual question wrt the Single Sign On behaviour.
Let's assume there are two applications /app1 and /app2, and there is a SSO
setup on them both. Now, user logs into the /app1 (which requires
authentication) and /app2 (which uses SSO Cookie, no authentication then),
and later on makes use of only one of them (say: /app1) for quite a long
time, so that this period outlives the session expiry date of the unused
application (/app2). Provided that both applications establish their own
sessions the one created in the scope of constantly used application
(/app1) wouldn't expire, while the second one definitely would.
Now the question: As both sessions are gathered into a higher-level SSO
session, would it be against the specification if *all* standard sessions
were aged (eg. by calling session.access()) on each request containing
valid SSO cookie? I suggest that there should be a flag on the SSO Valve,
that is org.apache.catalina.authenticator.SingleSignOn allowing users to
specify the behaviour. If nobody objects, I could try to provide apropriate
patch.
cheers,
/dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Standart Sessions included in the SSO Session expire
Posted by Dominik Drzewiecki <dr...@post.pl>.
Remy Maucherat <re...@apache.org> wrote:
> Dominik Drzewiecki wrote:
>> I have a conceptual question wrt the Single Sign On behaviour.
>>
>> Let's assume there are two applications /app1 and /app2, and there is
>> a SSO
>> setup on them both. Now, user logs into the /app1 (which requires
>> authentication) and /app2 (which uses SSO Cookie, no authentication
>> then),
>> and later on makes use of only one of them (say: /app1) for quite a
>> long
>> time, so that this period outlives the session expiry date of the
>> unused
>> application (/app2). Provided that both applications establish their
>> own
>> sessions the one created in the scope of constantly used application
>> (/app1) wouldn't expire, while the second one definitely would.
>>
>> Now the question: As both sessions are gathered into a higher-level
>> SSO
>> session, would it be against the specification if *all* standard
>> sessions
>> were aged (eg. by calling session.access()) on each request containing
>>
>> valid SSO cookie? I suggest that there should be a flag on the SSO
>> Valve,
>> that is org.apache.catalina.authenticator.SingleSignOn allowing users
>> to
>> specify the behaviour. If nobody objects, I could try to provide
>> apropriate
>> patch.
>
> The purpose of single sign on is to deal with authentication issues, not
>
> modify session lifecycle. Overall, you really need to design your web
> applications as if they were independent.
The applications are indeed independant. However the current implementation
of the SingleSignOn valve *does* modify the session - whenever user logs
out of one of the apps (I assume this means the invocation od
session.invalidate()) the rest of the sessions gathered under the same
SSOid get destroyed too. I just wanted to say that if we destroy sessions
of the other applications, we should also keep-them-alive, for the sake of
consistency. Just my $.02
>
> Of course, it is fine to implement your own custom behavior should you
> need it.
Of course, I know it ;) I was just wondering if a fix/enhancement to the
current behaviour might be required/welcome.
cheers,
/dd
PS. Sorry for posting twice, damn webmail client ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Standart Sessions included in the SSO Session expire
Posted by Remy Maucherat <re...@apache.org>.
Dominik Drzewiecki wrote:
> I have a conceptual question wrt the Single Sign On behaviour.
>
> Let's assume there are two applications /app1 and /app2, and there is a SSO
> setup on them both. Now, user logs into the /app1 (which requires
> authentication) and /app2 (which uses SSO Cookie, no authentication then),
> and later on makes use of only one of them (say: /app1) for quite a long
> time, so that this period outlives the session expiry date of the unused
> application (/app2). Provided that both applications establish their own
> sessions the one created in the scope of constantly used application
> (/app1) wouldn't expire, while the second one definitely would.
>
> Now the question: As both sessions are gathered into a higher-level SSO
> session, would it be against the specification if *all* standard sessions
> were aged (eg. by calling session.access()) on each request containing
> valid SSO cookie? I suggest that there should be a flag on the SSO Valve,
> that is org.apache.catalina.authenticator.SingleSignOn allowing users to
> specify the behaviour. If nobody objects, I could try to provide apropriate
> patch.
The purpose of single sign on is to deal with authentication issues, not
modify session lifecycle. Overall, you really need to design your web
applications as if they were independent.
Of course, it is fine to implement your own custom behavior should you
need it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org