I'd like all the official clients (.NET, PHP, Java, and Apache) to be consistent.
Would it be good to support both behaviors? I.e. ignoring tickets if a user is already present and also replacing sessions if a new ticket is presented. Similar to how Spring Security provides multiple options for what to do with sessions after authenticating. Thoughts? On Tue, May 25, 2010 at 2:24 AM, Joachim Fritschi < frits...@hrz.tu-darmstadt.de> wrote: > If you consider a new ticket a new authentication request what are you > doing with the old session if the ticket is invalid? > > Ignoring the ticket seems to be a poor choice if it is some kind of > intentional reauthentication. Then you would miss a killed TGT session for > example if you don't have Single Sign-Out enabled. But on the other hand > killing the old session would open a security hole where anyone could kill > my session and data by supplying me with a fake ticket embedded in some > link. > > Regards, > > Joachim > > > Am 25.05.2010 05:59, schrieb Scott Battaglia: > >> I would lean towards either generating it as an error or considering it >> a new session. >> >> The CAS Client for Java, if it sees a ticket, will treat it as a new >> authentication request. >> >> Cheers, >> Scott >> >> >> On Thu, May 20, 2010 at 3:25 PM, Joachim Fritschi >> <frits...@hrz.tu-darmstadt.de <mailto:frits...@hrz.tu-darmstadt.de>> >> wrote: >> >> One of the issues [1] that was recently opened for the phpCAS client >> has left me with a question i struggle with answering myself. The >> cas protocol definition hasn't helped me much. >> >> How should a cas client react if i submit a new [SP]T during a valid >> session and the new ticket was not explicitly requested with one of >> the clients own functions (recheck authentication with a gateway or >> renew call)? >> >> I have gathered a few options and have tried to analyse them below: >> >> 1. ignore the ticket >> a) remove it from the url and log it to the debug log >> b) ignore ticket and issue some error message that this is not >> supported + reload page button with ticket removed >> 2. validate the ticket >> a) if valid update the session with possible new data (attributes, >> ticket info for single logout etc.) >> b) if invalid >> I) ignore >> II) kill old session >> >> >> 1-b seems to be the best solution. Simple and clean. If they want to >> reauthenticated they can use one of the client supplied funtions. >> The customer gets an error and can resume the old session. >> >> 1-a is not that good since it will bury the error somewhere in the >> debuglog. >> >> 2-b-II is a really bad since it will allow a malicous user to kill >> your session with a bad ticket. >> >> That leaves the combination 2-a / 2-b-I . This is also a potential >> security hole since this will not revalidate a session but only >> update the attributes. (That should be cached by the server anyway, >> right ?) This might lead to some confusion for the users. >> >> Am i missing something? Thanks in advance for your ideas and input. >> >> Regards, >> >> Joachim >> >> [1] http://www.ja-sig.org/issues/browse/PHPCAS-61 >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org >> <mailto:cas-dev@lists.jasig.org> as: scott.battag...@gmail.com >> <mailto:scott.battag...@gmail.com> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> >> -- >> You are currently subscribed tocas-...@lists.jasig.org <mailto: >> cas-dev@lists.jasig.org> as: frits...@hrz.tu-darmstadt.de >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > > -- > Joachim Fritschi > Hochschulrechenzentrum (HRZ) > L1|01 Raum 248 > Petersenstr. 30 > 64287 Darmstadt > > Tel. +49 6151 16-5638 > Fax. +49 6151 16-3050 > E-Mail: frits...@hrz.tu-darmstadt.de > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
