Sure, the idea is to apply the same logic for the "Single Signon" than for regular session. Currently, a distinct cookie (or parameter) is created for this. The discussion is wether it should reuse in some way the "regular session" cookie (or parameter) or continue to use the distinct cookie (or parameter).
The problem I see with using the "JSESSIONID" cookie (or parameter) for the "single signon" is that there would be a clash between the SSO identifier and the identifier for the "ROOT" webapp. If you look at it from the "cookie side". Both cookie would have the "JSESSIONID" name and apply to the "/" path. So if somebody hits a webapp accessible from the "/foo" URL, we would need to create two cookies (if the SingleSignon valve is activated of course). We would need to create a "JSESSIONID" cookie for the "/foo" URL and a "JSESSIONID" for "/" URL for the single signon purpose. Now, after that, if the user hits the "ROOT" webapp, Tomcat would look for a session whose ID was the "JSESSIONID" given for the "single signgon" and it would not find the session, or worse, find another session. At that point, all hell break loose... On Mon, 8 Jul 2002, Tim Funk wrote: > Would this new solution be compatible with URL rewriting? (No cookies > being used) > > [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 ********************************************************************** Financiere Banque Nationale et NBCN n'assument aucune responsabilite quant a la confidentialite et l'integrite du present courriel en raison des risques d'interception inherents a l'Internet. Pour cette raison, toute opinion exprimee au terme des presentes ne reflete pas necessairement celle de Financiere 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]>
