[Openid-specs-fastfed] FastFed: Key Rotation
McAdams, Darin
darinm at amazon.com
Thu Oct 18 01:01:29 UTC 2018
This is topic #3 in preparation for next week’s meeting. It describes why key rotation (& certificate rotation) exists in the FastFed spec and summarizes the proposed behaviors.
Context:
-----------------------------
When I explain FastFed to others, the most common question I receive is "Will it solve certificate rotation?"
Many readers already understand why this question would occur. But, to get us all on the same page, I'll quickly describe the pain points which drive that question. Here is a representative example based on my own corporate experiences.
When first building out our corporate SSO infrastructure, a central team was responsible for all IdP configuration. People in the company would launch SaaS applications and then submit a request to the IdP administrators to finish enabling SSO. The central team would get everything working. And then, a year later, it would stop working because SAML certificates expired. In response, the IdP administrators took on the task of monitoring impending expirations and proactively reaching out to service teams to coordinate a rotation event. As the number of applications grew, this became a full time job for a group of people. It was a life of continuous rotation campaigns.
To improve the situation, the IdP administrators enabled self-service tooling. This tooling would automatically alert the application owners of impending expirations and provide them a new SAML Metadata file which they could upload into the SaaS application. This helped but wasn't perfect. Some people would hit the "snooze button" on the alert and the certificate would expire anyway. In addition, many SaaS applications cannot rotate without downtime because they lack support for multiple overlapping certificates during the rotation interval. So, rotations remained a hassle performed during off-peak hours to minimize impact.
Finally, as the value of SSO gained traction and more teams wanted it, we found that non-technical audiences were becoming common. For example, consider an "investor relations" team that wants SSO to a SaaS app. When informed they need to rotate certificates, the reaction might be "What's a certificate?". The whole process of configuring SSO is so confounding that they toss up their hands and ask the central team to just do it for them. This brings the problem back full circle where the organization is bottlenecked on a small central IT team.
To encourage broad adoption of SSO, we assert it is necessary to deliver an experience that "Just Works" for non-experts. This is the subtext of FastFed: Make SSO so easy that a 4-year old can do it. Hence, key rotation is in the spec. It must work, automatically.
What's in the spec:
-----------------------------
Key Rotation isn't difficult. The spec simply puts a formal contract around it, asserting the rules to be FastFed compatible.
Because the rules differ by protocol, it's cleanest to review SAML and OIDC separately.
Starting with SAML, the rules are effectively:
* IdP can generate new SAML Metadata, with a new certificate, at any time. It must do so before certificates expire.
* SP should periodically check for new SAML Metadata and import new certificates.
That's it. The remainder is fine print around E-Tag semantics, 301 Redirects, and the proper way to represent multiple certificates in a SAML metadata file. However, I recommend reading the fine print because that's where debates could be. I snuck in one knowingly contentious item about ignoring all changes in the SAML Metadata file except for the <KeyDescriptor>.
For details, see Section 5.3 of https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-SAML-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
Examining OIDC, the situation is a little different. OIDC has built-in key rotation mechanisms. Therefore, the FastFed profile simply describes the rules for using it. In summary:
* There are 2 secrets we care about for FastFed: the public/private key pair the IdP uses to sign the JWT, and the client_secret the RelyingParty uses to interact with the IdP.
* IdP can generate new keys at any time. It must do so before expiration.
* RPs should periodically pre-fetch the new keys, or pull them on-demand when the situation allows it.
Again, the rest is fine-print. See Section 5.3 of https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-OIDC-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
Discussion Topics:
-----------------------------
* Do others agree key rotation is a must-have?
* Is there anything in the proposed mechanisms that you disagree with? Or, anything missing?
* How much effort to implement? In other words, does this risk making FastFed "too big to fund".
More information about the Openid-specs-fastfed
mailing list