SP Migration to New Server

[Brett Melling]

Just thought I'd give a positive update on this thread. 

The fact that hosts files weren't sufficient for testing a new Shibboleth
implementation turned out to be down to some unique factors about the way we
have it implemented here, but the knowledge it *can* be that simple allowed
us to reconfigure things slightly, and now with appropriate hosts file
entries in place on the client and on specific servers in the chain we have
been able to successfully test what we'd wanted to test pre-migration. 

Thanks to Peter and Tim for contributions that led to that outcome. 

Regards,

Brett Melling



Website: https://calpendo.com 
LinkedIn: http://www.linkedin.com/in/calpendo |
https://www.linkedin.com/company/exprodosoftware/
General enquiries - info at exprodo.com 
Technical enquiries - support at exprodo.com

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober via
users
Sent: Monday, July 1, 2024 8:05 PM
To: 'Shib Users' <users at shibboleth.net>
Cc: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: SP Migration to New Server

Brett Melling <brett.melling at exprodo.com> [2024-07-01 19:51 CEST]:
> I don't recall the error but I didn't persist with it as I was sure - 
> given all the 'traffic' taking place in an SSO exchange - that DNS 
> would be used for more than the 'first hop'. But your answer suggests 
> not

Right. Ordinarily in SAML 2.0 WebSSO everything is mediated by the subject's
web browser, meaning you'd only need to manipulate the resolver on the
machine the browser runs on to point elsewhere for a given host name.
I can't speak to what else might be going on in your deployment might but
the workaround would be the same: Manipulate more local resolvers.
HTH,
-peter
--
For Consortium Member technical support, see
https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net