<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Scott, I get what you're explaining about the discovery URL.  I removed those attributes entirely since we don't plan on having a discovery service implemented any time in the near future.  I'm able to get my local test to work properly by setting the entityID to the old one but the ACS URL seems to be the issue now.  I don't know how our users are using the ACS url but in Jumpcloud you have to specify one & it <b>only works if I set it to the domain of the new server: <a href="http://sso.company.com/Shibboleth.sso/SAML2/POST">sso.company.com/Shibboleth.sso/SAML2/POST</a></b>...If i set it to <a href="http://shibboleth.company.com/Shibboleth.sso/SAML2/POST">shibboleth.company.com/Shibboleth.sso/SAML2/POST</a> (which I imagine most of users have it set to) it doesn't work...Is there any way to get around this on my end without forcing them to do anything?</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 5:29 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/2/18, 5:39 PM, "wknight" <<a href="mailto:wknight@quavermusic.com" target="_blank">wknight@quavermusic.com</a>> wrote:<br>
<br>
> Can you help specify? I can't decipher if that's a yes or no?<br>
<br>
I said don't change the entityID. Everything else is inevitably a mess and different degrees of breakage and problems, and all I'm saying is: don't change something that is not supposed to change.<br>
<br>
>  Should the new SP use the same entityID as the old one? <br>
<br>
Yes.<br>
<br>
> If so, then do my values for Host name,entityID, & discoveryURL line up with what you'd expect, given my situation<br>
> & goals?<br>
<br>
I imagine, except that that discovery URL is invalid, it's just nothing. Access it, and see.<br>
<br>
IdP discovery is how the system determines the IdP to use when the resource is accessed. It assumes direct access to the resource(s), and it has to point to a compliant discovery service such as the EDS tool we have or any of the others scattered around that knows how to work with the SP to return the IdP to use.<br>
<br>
Your whole issue with the customers using URLs that are now broken is because you're giving them direct access back into the SP with the IdP preselected. That's a bypass for needing to do the discovery step. Discovery never runs because the IdP is handed to it manually with those links. Which is fine until you have to change the URL, which is where you're at now.<br>
<br>
If your SP ever had to use that setting, it would break. I can easily imagine it is, and customers are accessing things in ways nobody is paying attention to and ending up with random failures, but I really have no idea.<br>
<br>
If you don't deploy a discovery mechanism, then you can't set that URL, it's really that simple. And if it ever comes into play, then there will be an error regardless, it's just a question as to what type of error shows up.<br>
<br>
Maybe it would be simpler if you simply looked at something else like the wiki.<br>
<br>
You won't have access to this page, but for illustration:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/MEMBER/Home" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/MEMBER/Home</a><br>
<br>
See what happens? That's discovery. That's what the setting is pointing to.<br>
<br>
Now take a different tack:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/Shibboleth.sso/Login?entityID=urn:mace:incommon:osu.edu" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/Shibboleth.sso/Login?entityID=urn:mace:incommon:osu.edu</a><br>
<br>
Right? Same links you're asking about. It sends you to my IdP at Ohio State. That bypasses discovery. That's what your customers are doing and why that setting is wrong, but doesn't matter for some definition of "doesn't matter".<br>
<br>
But setting it to a completely invalid location is obviously not useful.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><span style="font-size:12.8px">Will Knight</span><br></div><div dir="ltr"><div>Web Developer</div><div>Quaver Music LLC</div></div></div></div></div>