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:

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:

Surely KC implements both SAML SP and IdP. I am afraid that in a strict sense, there is also no KC-to-SP or SP-to-KC communiication. But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP communication is meant where KC is implementor of both parts. SAML 2.0 is designed to be extensible and allows Implementation specific extensions that are not interpreted if the receiving party does not know how to handle them. This is interoperable as long as the meaning of the original SAML message retains the same meaning. Hints like key ID are hence valid use of this extension. Just for the record - SAML IdP is represented by KC server, SAML SP part is handled by KC adapters. --Hynek On 10/31/2016 04:13 PM, John Dennis wrote:

Well, this discussion drove completely away from the original question. I prefer to focus on resolving the actual issue. Just to summarize: 1. In SAML, typically IdP to SP communication and vice versa is relevant. 2. KC implements IdP (server) and securing part of SP (adapter). Indeed, it does not implement actual service provider's functionality, only the part that in involved in SAML-related communication. 3. There are other IdP and SP SAML implementors than KC. 4. There is high chance, even though definitely not 100%, that KC IdP would communicate with SP secured by KC-native adapter. Please see the KC guide for further information [1]. 5. KC SAML adapters should be able to take advantage of knowledge of key ID to have signature validation performed using the right key on the first try. The original question was how to achieve Item 5 in terms of how to pass the key ID - whether in SAML protocol message or outside of it. Thank you --Hynek [1] https://keycloak.gitbooks.io/securing-client-applications-guide/content/v... On 10/31/2016 06:14 PM, John Dennis wrote: Did I say anything else?

On 11/01/2016 05:04 AM, Stian Thorgersen wrote: 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. 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. 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. 10) I believe Shibboleth v3 supports key rotation, if so it would be valuable to see how they approached the problem. -- John

On 11/01/2016 11:49 AM, Hynek Mlnarik wrote: By out of band I mean a non-standard exchange of information, not back channel. So yes, the only standard way I know is via metadata. The recommendation is such messages be exchanged over a secure transport such as TLS, since this is an HTTP-Redirect binding that means HTTPS. That means all the query parameters are pretty safe. Even if the keyID were modified by a nefarious actor what would the practical consequences be? I suppose that might depend on how strict your implementation is, here is the basic choices as I see them: 1) keyID lookup fails, you fail the protocol exchange. 2) keyID lookup succeeds but fails to validate signature. You fail the protocol exchange. However if either of the two above cases occur you could be more forgiving and treat it as if no keyID had been passed and fall back to iterating over the keys bound to the entity, something you have to implement anyway because the keyID will often be absent. The xmlSig spec is silent on what happens if the keyID (actually the KeyName) does not produce a known key. It does not specify if one may fallback to application specific context or not. I personally feel it's OK to use application specific context, if one accepts that then the keyID if present becomes a hint not a mandate. In summary, I don't see tampering with the keyID a significant risk over HTTPS or if it's treated only as a hint a serious problem that could be used to compromise the communication. -- John