Processing HTTP_Redirect from idp

Cantor, Scott cantor.2 at osu.edu
Fri Nov 2 14:37:31 EDT 2018


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




More information about the users mailing list