idpv5 CAS proxy tickets service identifer

[Paul B. Henson]

We tried to cut over to idp 5 a month or so ago but needed to roll it back as one of our applications failed to work properly with it.

This particular application uses CAS proxying; a user authenticates to it, and then it proxies that authentication to another application providing a web API.

I tracked down the failure to a difference in how the user facing CAS application doing the proxying is identified in the proxy ticket to the proxied to application.

The user facing application is accessed by the URL https://apps-tst.cpp.edu/idm, and receives a CAS ticket with that as the service URL.

In idp version 4, the identity of the service in the proxy ticket supplied to the proxied service is also https://apps-tst.cpp.edu/idm.

However, there are multiple nodes in a cluster behind a load balancer, and when a specific node requests a proxy ticket, it provides a callback URL pointing directly to it, not through the load balancer, as the nodes are not sharing state. A callback URL might be for example https://itwebtst01.apps-tst.cpp.edu/idm/?proxyResponse=true for node 1.

In idp v5,  the proxy ticket identifies the service initiating the proxy connection as "https://itwebtst01.apps-tst.cpp.edu/idm/?proxyResponse=true", the callback real, rather than as "https://apps-tst.cpp.edu/idm", the CAS service URL in the initial service ticket granted to the user.

As generally a service accepting proxying restricts what services are allowed to proxy to it, this change in identity broke the service during the upgrade.

Is this an intentional change in behavior? I don't recall seeing any release notes regarding it. I'm going to poke through the CAS related source code changes and see if I can find specifically what happened. I'm somewhat inclined to consider this a bug though, as the proxy callback URL can be any random thing as long as the appropriate certificate is trusted by the idp for it and the URL is listed in the CAS metadata. The previous behavior of identifying the proxying service using the CAS service URL itself rather than the proxy callback URL seems more intuitive, plus this is a breaking change that was not documented.

--
Paul B. Henson | Operating Systems and Network Analyst
henson at cpp.edu | California State Polytechnic University Pomona