Processing HTTP_Redirect from idp

Will Knight wknight at
Fri Nov 2 15:18:34 EDT 2018

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
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:
new SP entity:

On Fri, Nov 2, 2018 at 1:37 PM Cantor, Scott <cantor.2 at> 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
> To unsubscribe from this list send an email to
> users-unsubscribe at

Will Knight
Web Developer
Quaver Music LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list