5:51 a.m.
+1
This boils down to mistakes in the protocol implementations. I really don't
like either option of adding making the client send the version in the
protocol, nor having an option in the admin console. If really needed I'd
go for an option in the admin console. Adding a version doesn't work for
one, secondly even if it did it's not necessary to send this like it is in
other protocols. All clients need to be registered with RHSSO and the point
when they are registered allows giving the metadata about them. Other
protocols don't have this knowledge, so hence need to send the metadata as
part of a handshake.
In reality we should support rolling upgrades, not backwards compatibility
of adapters (at least not when the adapter is broken according to the
spec). That means we should support upgrading server first, adapter second.
In these cases it would probably just be simplest to require upgrading both
server and adapter at the same time.
On 3 March 2017 at 21:37, Jared Blashka <jblashka(a)redhat.com> wrote:
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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev