[keycloak-dev] Support for key rotation in SAML Redirect binding

[John Dennis]

On 11/01/2016 05:04 AM, Stian Thorgersen wrote:
> Hynek - your responses seems to be missing the list. Maybe you didn't
> use reply to all?
>
> If SAML is missing a standard way to specify an id for the keys used
> that's just stupid IMO. Signature validation is expensive and if there
> are multiple keys available it would be plain stupid to have to iterate
> over all to check. Granted in most cases we're only talking about a few
> keys.
>
> Sounds like the extensions approach is the best one. The id should be
> within the assertion and not passed separately.
>
> John - Keycloak has SP libraries as well, so this is an
> extension/optimalization that our adapters can use. Do other SP libs
> (i.e. mod_auth_mellon) go through the list of keys in order? If so we
> just need to make sure the list is sorted by most recent (and active
> key) first so there's a high probability the first key is the correct
> one. With regards to federation not sure what your comment that the
> instances needs to share keys is about. One IdP has a list of keys and
> the other IdP needs to figure out which of the keys are the correct one
> for an assertion.

1) SAML does have a mechanism to transmit a keyID, just not in the 
singular case when the HTTP-Redirect binding is used. The reason being 
the SAML message is transmitted as a URL query parameter which has 
practical length limitations. I believe OAuth and OIDC, in conjunction 
with JOSE, JWT etc. have similar restrictions to accommodate URL length 
constraints (sorry, can't give you pointers right off the top of my head 
for these other protocols).

2) In the singular case of the HTTP-Redirect binding you can still sign 
the AuthnRequest but unlike all other SAML protocol messages there is no 
official way to include a keyID. This was Hynek's issue/question.

3) The HTTP-Redirect binding is typically used to send a AuthnRequest 
from a SP to an IdP. It's not the only SAML binding you can use to 
transmit an AuthnRequest from a SP to an IdP, you can also use the 
HTTP-POST or SOAP bindings which do not have the length constraint 
imposed by the HTTP-Redirect binding.

4) Using another binding will not work for standard Web SSO because the 
flow is different. But that's OK because the proposed mechanism will 
only work with cooperating entities, e.g. both the SP and the IdP are 
Keycloak implementations. But since this is proposed only for KC to KC 
you're free to use whatever binding you want.

5) The only SAML message of concern here is AuthnRequest because only 
the HTTP-Redirect binding is affected by the keyID limitation. Although 
I believe it's legal to pass other SAML messages in a HTTP-Redirect 
binding I'm not aware of any such usage, so this is a very specific case.

6) My comment about instances sharing keys (actually keyID's) was in 
reference to the fact *both* parties have to know the keyID so you need 
a mechanism to share that information, the entity metadata is the best 
mechanism, but you could also do it via some out of band mechanism.

7) The period of time during in which multiple keys are in effect is 
expected to be relatively short. The chance of selecting the correct key 
on first attempt is high. The keyID issue affects only one protocol 
message. The lack of a keyID affects only KC to KC messages. Add all 
these together and you've got a very narrow case you're trying to 
optimize for. Is this where you need to be spending your optimization 
efforts? However this is an easy solution and goes directly to Hynek's 
question/issue, see next ...

8) I believe adding the keyID as an additional query parameter for 
HTTP-Redirect is the easiest and cleanest solution. SAML does not 
prohibit additional query parameters. Query parameters are consistent 
with the rest of the HTTP-Redirect binding. Of course one has to be 
careful concerning the total URL length. Of course you could also use a 
different binding as per item 3 because this is a KC to KC case.

9) Mellon does not currently support key rotation, It would be an RFE. 
but one we would be interested in implementing. Actually I don't think 
it would be implemented in mellon, rather it would need to be 
implemented in the lasso library that mellon uses for SAML. While doing 
that work we could also make sure keyID's are utilized.

10) I believe Shibboleth v3 supports key rotation, if so it would be 
valuable to see how they approached the problem.



-- 
John