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.
Yes. Must. If it's not checking the pgtUrl, it's not a sufficient
replacement for what the CAS clients are supposed to be doing.
The pgtUrl is authenticated by virtue of the https:// callback from the
CAS server, and so identifies the service authentically to the extent
that you trust the infrastructure of SSL certificates. The service URL
isn't authenticated. Proxying services should therefore be identified
by pgtUrls.
That doesn't mean I feel great about just making the change to the
current isAllowedToProxy() enforcement to match the pgtUrl instead of
the service URL in the services registry as it exists today -- that
feels clumsy, potentially resulting in multiple services registry
entries for a single conceptual service, in order to register both the
service URL and the pgtUrl. I suppose in most cases both URLs could
match an acceptable pattern https://portal.yale.edu/** etc., so in
practice that could be a fine solution, but offhand it feels better to
model pgtUrls more explicitly within the service registrations.
Andrew
On 8/25/2011 11:23 AM, [email protected] wrote:
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
