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