SP ability to handle multiple idp certs or idp metadata?

[Tom Scavo]

On Fri, Jun 17, 2016 at 8:23 AM, Luke Alexander <luke at brandwatch.com> wrote:
> On 17 June 2016 at 13:00, Tom Scavo <trscavo at gmail.com> wrote:
>>
>> This is called certificate migration or key rollover. In the case you
>> described, the IdP does all the work. If all SP partners refresh
>> metadata regularly, say, daily, the IdP simply introduces a new
>> certificate into metadata, waits one day, then starts signing
>> responses with the new key. It can then remove the old certificate
>> from metadata at its leisure.
>
> Ah yes, this makes sense, unfortunately the IDP in question is running ADFS3
> and the only way I found to handle it's metadata is to 'correct it' using
> the ADFS2Fed.py script so that the SP is able to use it; meaning that we are
> using a static metadata file for this IDP, perhaps I'm doing something wrong
> with this too and there is a magic setting for the SP to happily accept any
> ADFS3 formatted metadata?

The process of certificate migration described above works well in a
multilateral federation scenario as often found in higher ed.
Federations publish aggregates of metadata, IdP and SP deployments
automatically refresh that metadata, and everything Just Works.

That's an idealized situation. In practice, not all SPs participate in
the federation, so the IdP and SP end up sharing metadata out of band,
typically via email. When the IdP wants to migrate a cert, those SPs
become a Royal Pain. Each one has to be handled separately, and yes, a
possible outage might occur if the timing is off or someone screws up.

What you definitely don't want to do is to refresh metadata directly
from an IdP. That's dangerous, don't do it. You have to "own" the IdP
metadata, as you're doing now.

Tom