Support for signing key on hardware security modules

[Tom Scavo]

On Wed, Dec 20, 2017 at 7:51 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> My strategy is probably going to be to start using different signing keys for high-risk services that need frequent key rotation and a long lived key for other services. Of course, what OSU thinks is high risk is not the same thing as what an SP might think is high risk. I'm perfectly fine dividing the world into "handles key roll over" and "not", and rolling my key often for the former group.

That's a good idea.

> I just don't have a great way to recognize the two groups.

You could force a migration to a new key and a new set of endpoints.
You already know how to do this but for the record, it goes something
like this:

1. Clone the java webapp context tree onto some new server path. This
causes the endpoint location paths to change.

2. Configure the new webapp to sign with a new key.

3. On the designated flag day, *replace* the key descriptor and
endpoint locations in published metadata.

When you're satisfied that no more SPs will migrate:

4. Change the endpoint locations in published metadata to their
original values. At the same time, reintroduce the old key descriptor
so that now you have two key descriptors in published metadata.

Now you're all set up to reconfigure the IdP to sign with two keys.
Those SPs that successfully migrated after step 3 are your Good
Apples.

Tom