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

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.

valuable to see how they approached the problem.