On Tue, Aug 2, 2011 at 10:47 AM, Scott Battaglia <[email protected]> wrote: > On Tue, Aug 2, 2011 at 10:42 AM, William G. Thompson, Jr. <[email protected]> > wrote: >> >> On Tue, Aug 2, 2011 at 8:39 AM, Scott Battaglia >> <[email protected]> wrote: >> > I think you're misunderstanding the tool. Its not an emergency shut off >> > valve. Its a configuration tool (and its forward looking). >> > If: >> > 1. You change the pattern matching, it doesn't go invalidate all >> > services >> > that no longer match (nor does it ask them to stop using the attributes) >> >> I'm not sure what you mean by "go invalidate all services". If I >> change the URL for a service in SM, CAS will immediately stop vending >> STs for that URL, no? Likewise, if I disable the service in SM, those >> changes will have immediate effect. > > > Nope it won't. It won't vend NEW service tickets (just like disabling > proxying won't vend new PGTs). It however, will not stop existing sessions > from working.
Yes, of course, CAS has no control over existing application sessions. Yes, if I change the service URL or disable the service in SM, CAS will immediately stop vending STs for that service. Aren't we saying the same thing? > >> >> > 2. You change the attributes (it doesn't go ask all the services to stop >> > using them, nor does it push out new ones to the existing services). >> > etc. >> >> Do you mean "stop using" the ones the services already has, or "push >> out new ones" to services with existing sessions? >> Yes, of course, and I don't think that would be a likely expectation >> of someone using SM. > > So what you're saying is in some instances you expect it to be instantaneous > and affect services and in some instances you don't? You seem to extending my point into CAS having control over existing application sessions. I never had that expectation nor am I suggesting anyone should. What I'm saying is that if a CAS admin sets a service to disallow proxy, that the expectation is that proxy immediately stop working for that service. What that translates to, I think, is that CAS should stop vending PTs for that service in the same way it would stop vending STs if the cas admin marked the service disabled. Bill > >> >> >> > Likewise if you say this service isn't allowed to proxy, it won't issue >> > new >> > proxy granting tickets for that service. >> >> Sure, and I would also expect CAS to stop honoring PT requests from >> that service. > > >> >> Bill >> >> >> > >> > On Tue, Aug 2, 2011 at 8:36 AM, William G. Thompson, Jr. >> > <[email protected]> >> > wrote: >> >> >> >> On Mon, Aug 1, 2011 at 11:24 PM, Andrew Petro <[email protected]> >> >> wrote: >> >> > If an administrator disables a service from proxying, he expects that >> >> > disabling to immediately take effect. If he doesn't want to stop it >> >> > from >> >> > proxying, he wouldn't be disabling it. He wants to interrupt the >> >> > user's >> >> > proxying experiences. If users are presently proxying via an >> >> > application >> >> > that shouldn't be proxying (such that the admin is disabling it from >> >> > proxying), that's more likely to be a problem than to be a valid user >> >> > experience. >> >> > >> >> > Applications using PGTs already need to cope with PGTs expiring or >> >> > otherwise >> >> > becoming invalid (e.g. CAS server failure or accidental but explicit >> >> > user >> >> > logout from the CAS server). I'd think expiration or accidental user >> >> > logout >> >> > would expose the user to this user experience interruption far more >> >> > frequently than would tightening up this edge case. >> >> > >> >> > I think toggling a service's ability to proxy in the services >> >> > registry >> >> > should cause its already granted PTs if any to become invalid, should >> >> > cause >> >> > its already granted PGTs if any to become invalid, and should cause >> >> > it >> >> > to be >> >> > unable to acquire PGTs going forward (that much is current behavior). >> >> > This >> >> > is just what it naturally means for a service to be unable to proxy. >> >> > A >> >> > UX >> >> > note advising that things don't work as one would expect is less >> >> > helpful >> >> > than just making them work as expected. >> >> > >> >> > In short, yes, I think this deserves a JIRA and should be addressed, >> >> > though >> >> > I agree it's a fringe edge case and doesn't warrant a critical >> >> > immediate >> >> > fix. >> >> > >> >> >> I suppose there could be an option for a hard/soft set. >> >> > >> >> > Please no. >> >> > >> >> > I considered (and rejected) an argument for not addressing this edge >> >> > case >> >> > because it would increase cas server code complexity more than is >> >> > justified. >> >> > I reject this argument for just the reason you articulate, that the >> >> > present >> >> > behavior is too surprising and should be made to align with >> >> > expectations. >> >> > >> >> > But adding the behavior and then making it toggled by additional >> >> > configuration? Let's not add the complexity of more configuration >> >> > for >> >> > this. >> >> > >> >> > I just don't see a plausible use case for wanting a service to >> >> > continue >> >> > its >> >> > existing proxying but be disabled from proxying going forward -- a >> >> > real >> >> > usage of this feature would involve first retiring use of proxied >> >> > services >> >> > from the application being disabled from proxying. If an >> >> > application's >> >> > still >> >> > legitimately relying on proxying, you wouldn't be disabling it. >> >> >> >> Yes, that's what I was fishing for...a plausible use case. I'm >> >> convinced we should just tighten up the the behavior and invalidate >> >> current PGT/PT of Services that become marked as Can't Proxy. I agree >> >> that would likely be most consistent with expected behavior. >> >> >> >> Bill >> >> >> >> >> >> >> >> > >> >> > Andrew >> >> > >> >> > On 08/01/2011 11:15 PM, William G. Thompson, Jr. wrote: >> >> >> >> >> >> For me I think it comes down to expectations. I was surprise, and >> >> >> confused for a bit, when I set the Can't Proxy option, yet was still >> >> >> getting proxy tickets. >> >> >> >> >> >> If you setting this option against a live services, I imagine that >> >> >> folks would expect the user experience to get interrupted. >> >> >> >> >> >> I suppose there could be and option for a hard/soft set. >> >> >> >> >> >> Bill >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Aug 1, 2011 at 9:28 PM, Scott Battaglia >> >> >> <[email protected]> wrote: >> >> >>> >> >> >>> I'm on the fence on this. On the one hand, you'll interrupt the >> >> >>> user's >> >> >>> experience. On the other hand, its probably technically more >> >> >>> correct >> >> >>> to >> >> >>> disable it (or at least put a note that says that these items take >> >> >>> affect >> >> >>> going forward and do not affect existing sessions) >> >> >>> >> >> >>> On Mon, Aug 1, 2011 at 5:16 PM, William G. Thompson, >> >> >>> Jr.<[email protected]> >> >> >>> wrote: >> >> >>>> >> >> >>>> Folks, >> >> >>>> >> >> >>>> Ran into what may be an edge case, but likely easy to fix. Would >> >> >>>> like to get your thoughts prior to filing a jira. >> >> >>>> >> >> >>>> I'm using a sample CasApp that can get a PGT and PT for >> >> >>>> targetService. >> >> >>>> Everything working fine. >> >> >>>> >> >> >>>> * enable Services Management with proper config, everything still >> >> >>>> working >> >> >>>> fine. >> >> >>>> >> >> >>>> Test Case (edge case?): >> >> >>>> * Login in to CasApp (get PGT), then disallow proxy on CasApp via >> >> >>>> Services Management. >> >> >>>> * (haven't logged out of CasApp yet), still fetching PTs with the >> >> >>>> previously received PGT. >> >> >>>> >> >> >>>> Should CAS stop issuing PTs for a PGT from a service that has been >> >> >>>> marked as not allowed to proxy in Services Management? >> >> >>>> >> >> >>>> Bill >> >> >>>> >> >> >>>> -- >> >> >>>> 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 >> >> >>> >> >> >>> -- >> >> >>> 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 >> >> > >> >> > >> >> > -- >> >> > 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 >> >> > >> >> >> >> -- >> >> 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 >> >> >> > >> > -- >> > 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 >> >> -- >> 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 >> > > -- > 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 -- 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
