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) 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. Likewise if you say this service isn't allowed to proxy, it won't issue new proxy granting tickets for that service. 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
