> This is simple and works great, thanks.
>
Good. Just remember, if the proxied application is verifying the URL in the
proxy chain, it must accept the four URLs.
For example, someone logs into our portal and we have a PGT callback from CAS.
The PGT callback URL could have been one of the four as in the example below.
We then obtain a Proxy ticket and pass it to an external application. It
verifies the Proxy ticket with CAS and if successful, then validates it came
from an authorized proxy (the URI in the PGT callback).
Here is the list our external app is validating against:
@AUTHORIZED_PROXY= ("https://my.rutgers.edu/portal/aurora/CasProxyServlet";,
"https://my.rutgers.edu/portal/reo/CasProxyServlet";,
"https://my.rutgers.edu/portal/roadmaster/CasProxyServlet";,
"https://my.rutgers.edu/portal/silhouette/CasProxyServlet";);
Note that proxied apps are not required to verify the proxy URI. But IF they do
verify, they MUST check for all possible URIs.
Good luck.
Dan
Mikkel Refsgaard Bech wrote:
>> Yes, others do deal with the issue you are describing. In our
>> case, our portal (uPortal) is in a cluster (4 machines) and
>> required delivery of the PGT back to the specific server that
>> originated the CAS call.
>>
>> We accomplished this by defining 4 PGT callback URIs. For example:
>>
>> https://my.university.edu/portal/host1/CasProxyServlet
>> https://my.university.edu/portal/host2/CasProxyServlet
>> https://my.university.edu/portal/host3/CasProxyServlet
>> https://my.university.edu/portal/host4/CasProxyServlet
>>
>> The host information in the URI was then used to route the
>> PGT callback request to the correct server in the cluster.
>
> This is simple and works great, thanks.
>
> Mikkel
>
>
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
