Anyone had success/failures with changing IdP IP addresses?
Brian Koehmstedt
bkoehmstedt at ucmerced.edu
Thu Jul 24 17:54:07 EDT 2014
On 7/24/2014 2:40 PM, Cantor, Scott wrote:
> On 7/24/14, 5:33 PM, "Brian Koehmstedt" <bkoehmstedt at ucmerced.edu> wrote:
>> When we change the DNS records to have our IdP hostname point to a new
>> IP address, services start failing.
> You'll have to get more specific, but one issue is that the curl library
> on Red Hat 5 contains a bug that causes it to refuse to update DNS
> lookups. I filed it to get them to backport the fix, and they refused. So
> you'll have SPs basically holding onto old data making attribute queries.
> That assumes you actually have SAML 1 traffic that uses queries.
Yes, some of these services are definitely SAML1.
>> I've confirmed it's not a DNS cache issue.
> Then I have no idea what you mean by "failing". That's the only issue that
> could affect services, the rest is on your end, local infrastructure, load
> balancing, etc. So assuming that's not implicated, that leaves the DNS
> caching bug I'm aware of.
What I meant by confirming not a DNS cache issue is that both machines
stay up and I real-time monitor the Apache log files on each machine,
and I can see traffic die down to nothing on the old IP after we make
the DNS change.
>> One of my theories is that this is an SSL handshake problem.
> I don't see how.
>
>> I have contacted one SP and asked them to try and find errors in their
>> log file on my behalf, but I wasn't able to obtain anything useful so I
>> can't factually say what did or didn't happen on their end.
> Well, "failing" implies there's an error. Without even knowing what the
> error is...
>
>
Yes, so what I mean by failing is:
I have login URLs to these 5 services I previously talked about
testing. (I have a lot more services configured but frankly I don't
know how to log into most of them.) When I clear my cookies, and log
into any of those 5, I'll get redirected to our idp SSO page. I'll type
in my username and password, and then I get redirected back to the
service web application. Then each web application will show me some
kind of "error" or "not authorized" type message (not a Shibboleth
error, but a web app error unique to each app.) In other words, these
services aren't getting the attributes.
But I don't know why. No errors in idp-errors.log.
I'm not enough of a SAML expert to know how this works protocol-wise on
the backend between IdP and SP. I was under the impression that the SP
software would query the IdP, and that's why I said perhaps there's a
SSL handshake issue between SP software and IdP server, but again I
don't really know how that part of it works.
More information about the users
mailing list