Skickat från min iPhone
31 jan 2013 kl. 00:47 skrev "William G. Thompson, Jr." <[email protected]>: > Yes, the application holding the PGT should theoretically receive the > back-channel SLO callback, and could(should?) terminate its session > and relinquish the now invalid PGT. Whether or not that application > can directly end sessions with other applications accessed via PTs > would be app specific. > > The question is should those apps that where accessed via PTs also get > the SLO callback when the root TGT is destroyed via cas/logout (or > when expired via TicketRegistry "clean up", for the ones that have > that behavior). I suppose if one has bought into SLO, then you'd > probably expect that would be the case. I as a developer would expect pgts and tgts to behave the same way with regard to SLO. I'm not sure I'd expect SLO to cascade into PGTs. Personally, I'd be fine with calling it a limitation and document it. >> That the pgt is removed within the jpaticketregistry is interesting. Is that >> really the supposed behaviour? Makes me a bit worried since we use a >> different ticket registry which does not behave like that. > > PGTs, like STs, are anchored to a root TGT. If the TGT is expired via > cas/logout, I suppose one would expect the PGTs to likewise be > expired. This is potentially a separate, but related bug...needs > code review. Ok, I realise I have some code reading to do in order to silence the alarm clocks at the back of my head. Essentially, we are using the memcacheticketregistry presently, but will shift to a couchbaseticketregistry which behaves in the same manner. But it worries me if CAS would behave differently with the jpaticketregistry. Best regards, /Fredrik -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
