CAS proxy validation failing

[Andrew Morgan]

On Sat, 2 Mar 2019, Marvin Addison wrote:

> On Fri, Mar 1, 2019 at 6:27 PM Andrew Morgan <morgan at orst.edu> wrote:
>> It appears that v3.4.1 didn't try to validate the names...
>
> That is correct. 3.4.3 moved to conform HttpClient machinery on the
> work Brent did in that area for dynamic metadata loading (I believe)
> and the dev team agreed that using the same machinery was the correct
> approach.
>
>> However, I also notice that it seems to be trying to validate the
>> certificate for login.oregonstate.edu (the IDP hostname) in both versions.
>
> That is the root cause of the problem. That hostname is not in the set
> of allowed names:
>
> 2019-03-01 15:00:21,319 - DEBUG
> [org.opensaml.security.x509.impl.BasicX509CredentialNameEvaluator:255]
> - Trusted names being evaluated are:
> [https://myosu.oregonstate.edu:443/c/portal/login,
> lum-admin.ucsadm.oregonstate.edu]
>
>> Why is that being checked?
>
> I'd need more logs to say for certain. Let's start by turning up
> net.shibboleth.idp.cas to DEBUG and reproducing the error. That will
> give many more details about the CAS proxy machinery.

I turned up the logs, which showed the following additional log entries 
(just before the certificate checks that were previously logged):

2019-03-04 16:06:11,347 - DEBUG [net.shibboleth.idp.cas.flow.impl.ValidateProxyCallbackAction:129] - Attempting proxy authentication to https://lum-admin.ucsadm.oregonstate.edu:443/proxy/receptor?pgtId=PGT-1551744371347-UbFF9fVbvor8eSHAsWje9lbDDmEgZiH0WaEGJtzyV57yWURF6D&pgtIou=PGTIOU-1551744371347-c8nTc2OqkB9QWuJb1BprLhCKL9hyebhluHT8Kc2aKcM6iPKLno
2019-03-04 16:06:11,348 - DEBUG [net.shibboleth.idp.cas.proxy.impl.HttpClientProxyValidator:160] - Attempting to validate CAS proxy callback URI https://lum-admin.ucsadm.oregonstate.edu:443/proxy/receptor?pgtId=PGT-1551744371347-UbFF9fVbvor8eSHAsWje9lbDDmEgZiH0WaEGJtzyV57yWURF6D&pgtIou=PGTIOU-1551744371347-c8nTc2OqkB9QWuJb1BprLhCKL9hyebhluHT8Kc2aKcM6iPKLno

This wasn't too helpful, but on a whim I tried to wget that URL:

# wget https://lum-admin.ucsadm.oregonstate.edu:443/proxy/receptor
--2019-03-04 15:13:17-- 
https://lum-admin.ucsadm.oregonstate.edu/proxy/receptor
Resolving lum-admin.ucsadm.oregonstate.edu 
(lum-admin.ucsadm.oregonstate.edu)... 128.193.133.50
Connecting to lum-admin.ucsadm.oregonstate.edu (lum-admin.ucsadm.oregonstate.edu)|128.193.133.50|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://login.oregonstate.edu:443/cas/login?service=https%3A%2F%2Flum-admin.ucsadm.oregonstate.edu%3A443%2Fc%2Fportal%2Flogin%3Bjsessionid%3D8A76AB431C671E74F833396CD7947221 [following]
--2019-03-04 15:13:18-- 
https://login.oregonstate.edu/cas/login?service=https%3A%2F%2Flum-admin.ucsadm.oregonstate.edu%3A443%2Fc%2Fportal%2Flogin%3Bjsessionid%3D8A76AB431C671E74F833396CD7947221
Resolving login.oregonstate.edu (login.oregonstate.edu)... 127.0.0.1
Connecting to login.oregonstate.edu (login.oregonstate.edu)|127.0.0.1|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://login.oregonstate.edu/idp/profile/cas/login?service=https%3A%2F%2Flum-admin.ucsadm.oregonstate.edu%3A443%2Fc%2Fportal%2Flogin%3Bjsessionid%3D8A76AB431C671E74F833396CD7947221 [following]
--2019-03-04 15:13:18-- 
https://login.oregonstate.edu/idp/profile/cas/login?service=https%3A%2F%2Flum-admin.ucsadm.oregonstate.edu%3A443%2Fc%2Fportal%2Flogin%3Bjsessionid%3D8A76AB431C671E74F833396CD7947221
Reusing existing connection to login.oregonstate.edu:443.
HTTP request sent, awaiting response... 302 302
Location: /idp/profile/cas/login?execution=e1s1 [following]
--2019-03-04 15:13:18-- 
https://login.oregonstate.edu/idp/profile/cas/login?execution=e1s1
Reusing existing connection to login.oregonstate.edu:443.
HTTP request sent, awaiting response... 200 200
Length: 2331 (2.3K) [text/html]


So...  It appears they are protecting the proxy receptor endpoint with CAS 
authentication...  :/

I think Shibboleth is following the CAS protocol spec by validating the 
certificate name matches the hostname and by following the 302 redirect. 
It appears that v3.4.1 was also following the redirect, but it didn't care 
about the name mismatch or that the pgtId and pgtIou parameters were being 
lost in the redirects.

If this is all true, is there any setting in Shibboleth that would stop it 
from following the redirects?  Any other Shibboleth suggestions?

I'll be following up with the Luminis team here as well about their broken 
configuration.

Thanks,
 	Andy