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
