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

[Hynek Mlnarik]

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/2.3/topics/saml/java/general-config.html

On 10/31/2016 06:14 PM, John Dennis wrote:
> On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
>> Surely KC implements both SAML SP and IdP.
>
> KC is mostly an IdP. The only case I'm aware of where KC operates as 
> an SP is when KC federates to another IdP (i.e. KC is an identity hub 
> that is configured to authenticate against other IdP's). For the 
> optimization you're discussing to be workable the other IdP must also 
> understand the key id usage (i.e. is another KC instance) *and* share 
> the key id's. That seems to me to be an uncommon deployment.
>
>> I am afraid that in a strict sense, there is also no KC-to-SP or
>> SP-to-KC communiication.
>
> Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.
Did I say anything else?
>
>> But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP
>> communication is meant where KC is implementor of both parts.
>
> See above.
>
>> 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.
>
> Sure, but I still don't understand when you could take advantage of 
> this (see above). How often do you think KC is going to federate to 
> another KC instance that shares the same key ids?
>
>> Just for the record - SAML IdP is represented by KC server, SAML SP
>> part is handled by KC adapters.
>
>