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

[Hynek Mlnarik]

That trying to test every key is exactly what I'm trying to avoid. 
You're right that the verifying party needs to understand how to 
determine key ID. Fortunately, in the case where Keycloak is both 
signing and validating so this condition is satisfied.

I guess I'd have to go that way you suggest for REDIRECT if no other 
option proves viable, but trying to test every and each available public 
key to a verification of SAML signature seems both suboptimal and 
guessing - which is not a good sign of a secure solution. Though this 
may be needed for a communication between KC and non-KC, for KC-to-KC 
communication, this type of guessing should be avoided if a valid way 
exists.

On 10/31/2016 02:56 PM, John Dennis wrote:
> On 10/31/2016 09:22 AM, Hynek Mlnarik wrote:
>> The use case is to support key rotation with SAML, where the realm keys
>> are used for signing the assertions, similarly to key rotation support
>> for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
>> to a particular realm (IdP to SP direction, SP verifies IdP's
>> signature), and can be rotated at IdP on demand. IdP can provide
>> multiple valid keys for the realm, e.g. current and previous
>> certificates for signature validation to allow seamless key rotation.
>> Hence key ID information needs to be included with the assertion/message
>> to provide hint on which key was used for signing. For details, please
>> see comments KEYCLOAK-1881 [including comments].
>
> Yes, I understand the key rotation issue, what I don't understand is 
> why you need a key id. Both the SP and the IdP can identify the key 
> based on the entityID in the SAML message. In the case of key rotation 
> there is an ordered list of keys. You obtain the list based on the 
> entityID and iterate over the list trying each key in succession.
>
> What value is there in sending the key id in the SAML message? It's an 
> optimization that only works if each party knows how to interpret that 
> value and to the best of my knowledge there is no interoperability 
> mechanism defined for this. Remember it's the receiving party that 
> must select the correct key to verify the signature or decrypt a 
> message. Only the sending party can insert the key id into the 
> message, so even if you included the key id I don't understand what 
> it's accomplishing because the receiving party would have to interpret 
> that value (the sending party which knows the key based on ID but it 
> would never see the key id in a message).
>
>