Shibboleth and CAS

[Nathan Lewan]

hello!

I am trying to get CAS 6.1.0 to integrate with a SP that uses shibboleth.

i appear to have everything in place, however they are requiring my responses to have in the AuthnStatement a SubjectLocality entry.

It is currently empty in all my responses. Here's what it looks like:

<saml2:AuthnStatement AuthnInstant="[removed]"  SessionIndex="[removed]" >

    <saml2:SubjectLocality/>

    <saml2:AuthnContext>

        <saml2:AuthnContextClassRef>

            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

        </saml2:AuthnContextClassRef>

    </saml2:AuthnContext>

</saml2:AuthnStatement>

As you can see, it's blank, and I have no idea how to get it populated!

Any hints would be appreciated. Looking for info on this, you can find much related to shibboleth, but I have not found anything on how one could get CAS to populate this.

thanks!

[David Curry]

We just ran into this recently with an older version of CAS (5.2.9).

CAS populates the SubjectLocality by doing a reverse DNS lookup on the IP address of the entity that's calling it (the application the user is trying to log into). If the DNS lookup fails, then it doesn't put anything in there, which makes Shibboleth very unhappy.

In our case, the fix was to get the company running the application that was calling CAS to register DNS entries for their IP addresses. All of a sudden everything started working.

--Dave

--

DAVID A. CURRY, CISSP
DIRECTOR • INFORMATION SECURITY & PRIVACY
THE NEW SCHOOL • INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 646 909-4728 • david...@newschool.edu

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CABeAwjkrJ8hk5geJbz_tbN1NgVSxESjAGUAfqcmOd8vpTHuUYQ%40mail.gmail.com.

[Nathan Lewan]

very interesting, thanks!

so i tried to do a reverse dns lookup on the entity host based on the shibboleth entityid's hostname, and came up with no record.

they are not being super helpful with me, so I tried to cheat. I just added a reverse lookup zone on the dns server that CAS talks to, and added the entry in there as a test. It did not seem to help, but:

1. I don't know if a cheat like that would actually work (this is just temporary, proof of concept, no way would I leave it like that in production)

2. I have not restarted CAS. I did do a dig -x on the CAS host, and it successfully reverse-resolved the IP of the entity server

thanks very much for the quick response, i have a lead which feels very good!

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CA%2Bd9XAPbf2nhAiOuG7_R8-M7v4KUgjbCDnJunNU47V%2BVc%2BgHsw%40mail.gmail.com.

[Mike Osterman]

Hi Nathan,

I highly expect that #2 is why it's not yet working. Java, by default, never lets go of a DNS resolution record until the application restarts. You have to pass an argument at startup of your CAS application to indicate an expiry TTL.

I did this recently on our CAS server when we did some work with our Activity Directory that provides group membership and needed it to get a new IP address for the AD LDAP server(s). 

-Mike 

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CABeAwjmoAjjV4ryjQ3yhXfMsky9gWAQZf2CBi7FtzDJ8m-yt2w%40mail.gmail.com.

[Nathan Lewan]

thanks everyone for the help so far.
I did just do a restart of the service, and it would not populate that field. I checks another service with a similar setup, and that also does not have the subjectLocality populated, but that one works just fine.




so here's the actual error i'm seeing:
    xmltooling::ValidationException at (https://[hostname]/SAML2/POST)
    SubjectLocality must have Address or DNSName.

Looking at the code for CAS, this appears to be the function to populate the subjectLocality, but if i'm reading that right, it's trying to populate it with the CAS host address?

protected SubjectLocality buildSubjectLocality(final Assertion assertion, final RequestAbstractType authnRequest,
final SamlRegisteredServiceServiceProviderMetadataFacade adaptor,
final String binding) throws SamlException {
val subjectLocality = SamlUtils.newSamlObject(SubjectLocality.class);
val hostAddress = InetAddressUtils.getCasServerHostAddress(casProperties.getServer().getName());
val issuer = SamlIdPUtils.getIssuerFromSamlObject(authnRequest);
LOGGER.debug("Built subject locality address [{}] for the saml authentication statement prepped for [{}]", hostAddress, issuer);
subjectLocality.setAddress(hostAddress);
return subjectLocality;

}

is the subjectLocality supposed to be my address, or their address?

[David Curry]

Back when I was debugging this the last time, I ran a bunch of tests against all the SAML SPs we have authenticating against our CAS servers and captured the SAML being exchanged, and in every case the SubjectLocality element contained the IP address of the SP, not the CAS server.

For example, when I log in to Workday:

<saml2:AuthnStatement AuthnInstant="2020-09-24T11:10:34.218Z" SessionIndex="_9074398769568118801">

  <saml2:SubjectLocality Address="209.177.165.18"/>

  <saml2:AuthnContext>

    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>

  </saml2:AuthnContext>

</saml2:AuthnStatement>

The 209.177.165.18 address belongs to Workday, not to us.

You might want to grab the "SAML Chrome Panel" extension, which will let you examine the entire SAML exchange between the SP and the IdP.

--Dave

--

DAVID A. CURRY, CISSP
DIRECTOR • INFORMATION SECURITY & PRIVACY
THE NEW SCHOOL • INFORMATION TECHNOLOGY

71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003
+1 646 909-4728 • david...@newschool.edu

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/cb8710c4-10a0-438f-a0a4-56c146a11bcfn%40apereo.org.

[Nathan Lewan]

ok, good to know, thanks.

i've been using that extension, as well as one on firefox. That's how i was getting the SAML exchanges and saw the empty SubjectLocality

May seem like a silly question, but i'm gonna just ask it: does CAS, the application, require knowledge of DNS servers/network configurations in its own configs, or does it piggy back off of the OS connections.

Just trying to think of a reason that, given the reverse DNS entry is there, CAS itself would not pick up on it, while the server host OS would.

I'll keep you posted, and I appreciate the time you have given me on this!

[David Curry]

It uses whatever the system has for DNS. But doing PTR records for address spaces you don't own in your own DNS is tricky; you may not be "fooling" it the way you think you are unless you're running your own faked root servers, etc.

You might be able to do it with a local hosts file and nsswitch.conf...

David A. Curry,  CISSP
Director • Information Security & Privacy
The New School • Information Technology
71 Fifth Ave., 9th Fl., New York, NY 10003
+1 646 909-4728 • david...@newschool.edu
Sent from my phone; please excuse typos and inane auto-corrections.
   

[Nathan Lewan]

thanks again,

since I am not seeing a SubjectLocality field on multiple SAML service definitions I have in my CAS deployment (all the others work though), and I know that my CAS service is behind a load balancer, I am wondering if that plays into it at all. I'll have to dig.

This particular Service Provider does NOT have reverse DNS set up, while the other working SAML services in my CAS deployment do have reverse DNS. But even in those cases my CAS server is not populating SubjectLocality, so I'm guessing the other SP's aren't being as strict.

i'll let you all know what I find.

[Nathan Lewan]

welp, got it working. This is embarrassing.

I had to put the log level to 'trace' to see the error.

in my cas.properties file i had this

cas.server.name=https://${hcc.local.hostname}.harford.edu:${hcc.cas.port},

I use variables passed in to set the hostname and port. But do you see it? I added a comma at the end of the line... and it messed up the parsing, and that cascaded down the service setup from there.

so remember folks, commas are bad : )