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

[Stian Thorgersen]

Hynek - your responses seems to be missing the list. Maybe you didn't use
reply to all?

If SAML is missing a standard way to specify an id for the keys used that's
just stupid IMO. Signature validation is expensive and if there are
multiple keys available it would be plain stupid to have to iterate over
all to check. Granted in most cases we're only talking about a few keys.

Sounds like the extensions approach is the best one. The id should be
within the assertion and not passed separately.

John - Keycloak has SP libraries as well, so this is an
extension/optimalization that our adapters can use. Do other SP libs (i.e.
mod_auth_mellon) go through the list of keys in order? If so we just need
to make sure the list is sorted by most recent (and active key) first so
there's a high probability the first key is the correct one. With regards
to federation not sure what your comment that the instances needs to share
keys is about. One IdP has a list of keys and the other IdP needs to figure
out which of the keys are the correct one for an assertion.



On 31 October 2016 at 18:14, John Dennis <jdennis at redhat.com> 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.
>
> > 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.
>
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>