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