Hi Constin,
I thought about your idea yesterday night. I understand it and see your
point. As I see it, currently the cookie are build as such:
<session ID>.<jvmroute>
And with the SSO patch proposed we would have also:
<SSO session ID>.<jvmroute>
Currently, the SSO cookie does not have the <jvmroute> appended.
But, the way I understand what you say, we would have either:
<SSO session ID>.<jvmroute>
<SSO session ID> being used as the <session ID> in each webapp, or:
<session ID>.<SSO session ID>.<jvmroute>
I think the first alternative would be superior. But since it would mean
to substantially modify the way the session IDs are generated, it may be
more appropriate to wait for a stable release of 4.1.X. At that point,
I would be willing to propose a patch if everybody agrees on this approach.
For now, I'm more eager to see a stable 4.1.X, than to have SSO work in all
scenarios :)
Agreed?
On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:
> On Mon, 8 Jul 2002, Denis Benoit wrote:
>
> > I think it would be difficult, since JSESSIONID is distinct for each
> > webapp on a Tomcat, only JSESSIONIDSSO (if the SingleSignon valve
> > is activated) is common to all webapps.
> >
> > I'll try to think of something, but if you think of something first,
> > let me know :)
>
> Well, my thinking is that in order to have 'single signon' you need
> a way to have a single cookie ( or path param if cookies are disabled )
> across all webapps. Whatever mean to get that as JSESSIONIDSSO,
> it can be used for JSESSIONID as well.
>
> So I would add a hook into the session id generator - and have
> the single signon use the hook to push session ids.
>
> If we want to have distinct sessions in each webapp - the session
> id would consist of the 'common' part and a per-webapp part.
>
> In general, my view of single signon is that each app must
> redirect to an auth application ( similar with kerberos for example)
> and use the certificate as session id for all webapps.
>
> Costin
--
Denis Benoit
[EMAIL PROTECTED]
T�l: (514)879-5168
**********************************************************************
Financi�re Banque Nationale et NBCN n'assument
aucune responsabilit� quant � la confidentialit� et l'int�grit� du
pr�sent courriel en raison des risques d'interception inh�rents � l'Internet.
Pour cette raison, toute opinion exprim�e au terme des pr�sentes
ne refl�te pas n�cessairement celle de Financi�re Banque Nationale
et de NBCN.
**********************************************************************
Due to the security risks involved in sending information over the
Internet, National Bank Financial and NBCN cannot
be held responsible for ensuring the confidentiality and integrity
of the present e-mail. For this reason, the opinions expressed herein
do not necessarily reflect those of National Bank Financial
and NBCN.
**********************************************************************
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
