Processing HTTP_Redirect from idp

[Will Knight]

Thanks for your elaborate explanation, Scott.

So two follow up questions for clarification:
1) Are you suggesting the new SP should use the same entity ID as the old
SP?
or
2) If we do treat this as a "flag day" and notify our users: what
specifically do we need to ask them to do?  If you're suggesting we need to
get our idp users on a whole different entityID that would mean changing
old SP entity: https://shibboleth.company.com/shibboleth
to
new SP entity: https://sso.company.com/shibboleth

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

> More background,
>
> Even if you changed your SP's entityID, key, everything, and just had two
> separate metadata instances altogether, that isn't inherently the problem.
> The issue is that policy in the IdP is around the entityID. if you change
> your entityID, you break that policy, whatever it happens to be in every
> customer's case.
>
> In broken IdPs like ADFS or other non-metadata-driven systems, it's even
> worse, since changing the entityID amounts to forcing a complete redo of
> the manual nonsense they require to actually federate with an SP.
>
> But if you *don't* change the entityID, that also creates constraints on
> the old and new systems. You can't change the encryption key in that
> scenario because one piece of metadata can't distinguish the two cases.
> Leaving logout aside, you can always add new ACS endpoints because the
> endpoint to use at runtime is in the original request. The key isn't (bug
> in the standard I would say), so the IdP has to pick one key to encrypt
> under, and so it's got to be the same key for old and new for both to work.
>
> With federations like InCommon, slipping a second SP into the metadata is
> nothing, it's fine. But it's still a second SP and all the rules for the
> original simply don't apply to the new one and you're forcing every IdP to
> do work when they would otherwise need to do nothing.
>
> That's why you don’t change your entityID, and why you don't change the
> encryption key in an old/new system fashion, but in much more deliberate
> fashion. But you're free to add new servers at will.
>
> But without a metadata exchange model up front that accomodates all this
> without creating fundamental scaling and security problems, you're swimming
> upstream. That's the sum total of the reason InCommon charges money and
> what the value for that money is. I don't know how to get anybody to
> understand this in an elevator pitch, but I'm fairly certain that to most
> companies, "eh, let it break, somebody'll fix it" is a rational strategy.
>
> You're in a minority by not just treating this as a flag day and
> announcing the change on Twitter. I also suspect your non-higher ed
> customers don't see any of this as something to care about. I couldn't tell
> you why we seem to be different. But unfortunately nobody but us adopted
> the mechanisms in the standard designed to make any of these changes
> possible.
>
> -- 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/1cbe1feb/attachment.html>