IdP Signing Certificate question
cantor.2 at osu.edu
Thu Jan 21 18:15:45 UTC 2021
On 1/21/21, 12:58 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> - A tagging/metadata-based strategy for controlling the key used by all broken services so that a future change can be
> automated for all the non-broken services and the broken ones controlled on an individual basis.
I never really wrote up what I did, but basically I defined multiple SecurityConfiguration beans with the various keys (and/pr certificates) that are in use, along with an aliased bean for the one that's a default. I labeled them by year (e.g. osu.SecurityConfiguration.2004 and osu.SecurityConfiguration.2019)
I also added an unpublished keypair under the name "Canary" to allow probing SPs for total breaks, since accepting that key means they accept anything, which I can test whenever I want to.
I wired up metadata-driven support for looking up the securityConfiguration property into my relying party definitions, and then I started adding tags to metadata or via filters every time I moved an SP over to the new key so that it was "locked" to that key and no longer using the default key. Everything not broken is just left defaulted.
By the end, I had migrated all the 2004 tags to 2019, while everything else floats. The next time (if it happens) I can publish a new key in InCommon and then float all the untagged systems to it immediately as a new default after 24 hours while everything else is locked to the 2019 bean. Then I can start updating and retagging the broken ones to use the new bean one at a time to get them all updated, and at any given time it's trivial to identify which ones are on which key.
More information about the users