8:22 a.m.
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].
--Hynek
On 10/31/2016 02:09 PM, John Dennis wrote:
On 10/31/2016 07:48 AM, Hynek Mlnarik wrote:
> Hi All,
>
> re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
> for signing for every signature (assertion/document-level) to validate
> the signature with the correct key. In POST binding, dsig:KeyInfo
> element bears this information in dsig:KeyName both for signed
> assertions and for the whole document (a.k.a. protocol message).
>
> For REDIRECT binding in SAML, there is currently no place where KeyID
> can be inserted on document level. The document signature in REDIRECT
> binding has to be removed from the document (line 578 in [2]) and
> replaced by the Signature query parameter, so it is not advisable to put
> key ID there.
>
> To solve this, there are multiple options:
>
> 1) Modify SAML assertion by adding <Extensions> element that would
> include document signing key ID. For consistency reasons, this would
> also be present for POST binding SAML documents. This only works for
> SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
> 2) Pass signing key ID in REDIRECT query parameter (next to Signature
> and SigAlg parameters) - seems not strictly against the spec but weird
> 3) Pass signing key ID in custom HTTP header - this might impact
> clustering setup and is even weirder than the previous item
> 4) Claim REDIRECT binding not supporting signatures signed with key
> rotation and only support them for POST bindings (for REDIRECT, it would
> only work for preset public keys). This is not a viable option for
> dynamic key retrieval, so including just for completeness.
>
> Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
>
> Thanks
>
> --Hynek
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-1881
> [2]
> https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
I'm confused because I don't understand what problem you're trying to
solve. It sounds like you want to lookup up a key based on an ID
received in a SAML message. But you already know the keys associated
with the client because they are bound to the client via the client's
entityID. Could you clarify please?