Andrew, thank you for the extensive reply. In my particular environment, I want only one policy on accepting proxy tickets for all CAS clients, so enforcing at the CAS server is preferable. In my environment, it is not necessary (or desirable) for each CAS client to decide whether or not accept a Proxy Ticket from a given proxy chain. In other environments, where each CAS client (representing a given service) may trust a different set of proxy chains, this won't be sufficient.
It seems that you do agree that if "server side" enforcement of proxy chains is done, it should ideally include a check on the pgtUrl. Thanks, David Ohsie EMC Corporation -----Original Message----- From: Andrew Petro [mailto:[email protected]] Sent: Wednesday, August 24, 2011 10:57 PM To: [email protected] Subject: Re: [cas-user] Should "isAllowedToProxy" be called on the service matching the pgtUrl? The "allowedToProxy" feature in the Services Registry isn't sufficient to replace the functionality of CAS client libraries in validating the proxy chain, nor to fulfill their responsibility to do so. The service receiving the proxy ticket needs to decide that the proxying service was authorized to proxy *to it*. In the special case where a CAS server has only one service permitted to proxy, then ensuring that's the only service that can get proxy tickets might be sufficient, but in the general case, just because a service is allowed to proxy to some other service doesn't mean any another service should accept its proxy tickets. Relying, as a CAS client, on the expected proxying service being the only one allowed to proxy seems short sighted. In the future, another service might need to generate proxy tickets -- is it certain that the existing CAS clients will then be updated to validate their expectations of the proxy chain? Better to configure to validate those proxy chains in the first place. As such, turning off "allowedToProxy" on services is a way to discourage services from getting proxy tickets that no one ought to trust. It's something -- if no one ought to be accepting these proxy tickets, then CAS might as well not issue them. Indeed, if you're not using proxy tickets, then you might as well configure the registrations such that no service can proxy, or better yet unmap the /proxyValidate endpoint so that no service can validate proxy tickets. As long as we're registering services, it might be worth registering the pgtUrl associated with each service, and then only issuing the PGT callback to the registered proxyCallbackUrl associated with the service. That would resolve the distinction here about matching on pgtUrl vs service URL. All in all, I think I'd favor accompanying that improvement with something that's truer to the existing allowedProxyChains feature. The targets of proxy tickets must be registered -- it would be a fine thing to be able to articulate in their service registry registrations the set of proxy chains allowed to proxy to each service. A good implementation could even validate that the chains are valid -- that the pgtUrls referenced are allowed to proxy. If a registered service could rely on proxy chain constraints being enforced by the CAS server, then it could dispense with inspecting the proxy chain in the CAS client library. I expect updating the services registry will be a theme for a CAS 3.5 release and reworking this should be addressed alongside other services registry improvements. Andrew On 8/24/2011 4:21 PM, [email protected] wrote: > Dear CAS Experts, > > I was experimenting with restricting services that are allowed to get a PGT > using the services manager. What I was intending to do was to restrict > which service could act as a proxy (get a PGT) in CAS itself instead of in > the CAS client. I wanted to do this so that I can set the policy on which > services can proxy at a central location (CAS) rather than in each CAS client > which validates the proxy chain. > > Another way of putting this was that I wanted to put the restriction on the > proxy chain into CAS rather than having each CAS client make its own decision. > > So rather than having each CAS client configure > "allowedProxyChains=https://proxy.example.com";, I wanted to register > https://proxy.example.com as a service in the service registry and mark it as > "allowedToProxy = true" (and disable proxying on other services). Then even > if the client doesn't check the proxy chain, our central policy applied in > CAS still takes effect. > > However, I discovered that these are actually not equivalent restrictions. > When CAS calls "isAllowedToProxy" on a service to determine whether or not it > may get a PGT, it uses the URL of the service in the service ticket, rather > than using the "callback URL" in pgtUrl. So if the ST was for > https://proxy.example.com, but the pgtURL was > https://notallowedtoproxy.example.com, then CAS would allow the PGT to be > sent; however the "equivalently configured" CAS client would not accept PT's > from this PGT if it was configured to take only > "allowedProxyChains=https://proxy.example.com";. > > I wonder if it would make more sense for the "isAllowedToProxy" call to be > made on the service matching the pgtUrl rather than (or in addition to) > checking on the service that matches the ST's service. Then CAS and the CAS > clients could apply similar restrictions, and CAS would be doing some > validation of the identity of the proxy via it's https callback and basing > policy decisions based on that authenticated identity. > > Any thoughts from the experts? > > David Ohsie > EMC Corporation > Office: 410-358-9554 > Cell: 410-428-8035 > > > -- 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-user -- 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-user
