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