[keycloak-dev] Client adapters backwards compatibility

[Jared Blashka]

I'm not on the Keycloak dev team (obviously) but can't you backport a patch
to RH-SSO 7.0 to fix the broken adapter behavior rather than building in a
very specialized flag that will be present in every single SAML client
configuration going forward where it's completely unnecessary a large
majority of the time?

It doesn't make sense to me to build a workaround into the IDP code just to
accommodate one specific version of one specific client library. If this
was any other client library with this problem I feel like the response
would be that the client library needs to be updated rather than
maintaining a workaround in the IDP. If RH-SSO 7.0 is still a supported
product then it should still be eligible for receiving updates.

Jared

On Fri, Mar 3, 2017 at 2:37 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> On 3/3/2017 2:11 PM, Bill Burke wrote:
> >
> > On 3/3/17 10:29 AM, Stan Silvert wrote:
> >> Versioning is always a pain.  But it's much better for us to manage the
> >> pain than leave it up to customers.
> >>
> >> On 3/3/2017 9:35 AM, Bill Burke wrote:
> >>> I agree with you in principle stan, but there are other issues:
> >>>
> >>> * For OIDC it is a get request with simple query parameters. There is
> no
> >>> request object you can hide the version information in and you'd have
> to
> >>> add another query param.
> >> I don't think you need to hide the version.  Just add another query
> >> param.  Then if version is not present, you at least know it's an old
> >> client.
> >>> * As Hynek said, for SAML IDP initiated SSO, there is no client
> >>> request.  User logs in then assertion is sent to client.
> >> Would it make sense to send client version as part of the login?
> >>
> >> At some point, the client has to send a message to the server.  You can
> >> always piggyback the version onto whatever message is sent.
> > Untrue.  With SAML IDP initiated SSO, the client does not have to send a
> > message to the server, ever.  Also, this isn't a communication protocol,
> > its an authentication protocol, so once the protocol is finished,
> > there's no more piggybacking that can be done.
> >
> >>> * Keycloak 1.x and 2.x are already out the door and don't submit a
> >>> version.  2.5.x fixes the problem of the OP, 1.x doesn't so there is no
> >>> way to tell the difference.
> >> Yea, I raised this issue in Brno last year.  It's not too late to fix
> >> the problem going forward though.
> > We can and should propagate version, but it still doesn't solve the
> > problem of a 1.9.x adapter talking to Keycoak 2.5.x, nor does it solve
> > idp initiated SSO issues.
> I'm on board with that.  Let the client send a version whenever possible.
> >
> > Bill
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>