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?
--
John