Processing HTTP_Redirect from idp

[Will Knight]

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 *only works if I set it to the
domain of the new server: sso.company.com/Shibboleth.sso/SAML2/POST
<http://sso.company.com/Shibboleth.sso/SAML2/POST>*...If i set it to
shibboleth.company.com/Shibboleth.sso/SAML2/POST (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?

On Fri, Nov 2, 2018 at 5:29 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 11/2/18, 5:39 PM, "wknight" <wknight at quavermusic.com> wrote:
>
> > Can you help specify? I can't decipher if that's a yes or no?
>
> 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.
>
> >  Should the new SP use the same entityID as the old one?
>
> Yes.
>
> > If so, then do my values for Host name,entityID, & discoveryURL line up
> with what you'd expect, given my situation
> > & goals?
>
> I imagine, except that that discovery URL is invalid, it's just nothing.
> Access it, and see.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Maybe it would be simpler if you simply looked at something else like the
> wiki.
>
> You won't have access to this page, but for illustration:
>
> https://wiki.shibboleth.net/confluence/display/MEMBER/Home
>
> See what happens? That's discovery. That's what the setting is pointing to.
>
> Now take a different tack:
>
>
> https://wiki.shibboleth.net/confluence/Shibboleth.sso/Login?entityID=urn:mace:incommon:osu.edu
>
> 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".
>
> But setting it to a completely invalid location is obviously not useful.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
Will Knight
Web Developer
Quaver Music LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181102/041b3622/attachment.html>