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

[Hynek Mlnarik]

On Tue, Nov 1, 2016 at 4:23 PM, John Dennis <jdennis at redhat.com> wrote:

> 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.
>

Which out of band mechanism you mean? I am not aware of any standard one.


> 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.
>

Key ID in query parameter (or any additional query parameter) in the
parameter would not protected by the signature, only
SAMLRequest/SAMLResponse, RelayState, and SigAlg are. Including it in SAML
protocol message has hence benefit in Key ID protection.


> 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.
>

That would be valuable.

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


I agree, thanks for the pointer.