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
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
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
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
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,
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:
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
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
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,
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:
Hi everybody,
I have a Shibboleth IDP v3.4.3 with the plugin shibcas 3.2.3 for delegating
authentification to my CAS server in version 5.3.3.
On my CAS server, for specific service, users should do an authentication
by login/password AND Google OTP.
My problem is the next, my CAS return a
11 matches
Mail list logo
