[keycloak-dev] Client adapters backwards compatibility

[Stan Silvert]

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.
>
> * 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.
>
> * Client templates can be used to manage large sets of clients.
That might help, but it's not really a solution.
>
>
>
> On 3/3/17 9:11 AM, Stan Silvert wrote:
>> On 3/3/2017 3:15 AM, Hynek Mlnarik wrote:
>>> Determination of client version from client message would not work for
>>> IdP-initiated SSO (there is no client message to determine version
>>> from), so +1.
>> I don't understand this.  I don't know exactly how we implement
>> Idp-initiated SSO, but if you are talking to a client then, by
>> definition, you are exchanging messages.  In every protocol I can
>> remember, part of the handshake includes transmitting the protocol version.
>>
>> If you don't do this, it leads to problems.  With the switch, somebody
>> has to manually manage the protocol version of potentially thousands of
>> clients.  If somebody sets the switch wrong, the client can't
>> communicate.  Out of the plethora of possible issues, how long will it
>> take before somebody realizes that the version switch is wrong?
>>
>> Also, you might have the switch set incorrectly, but the client still
>> seems to communicate fine because it doesn't run into unexpected
>> messages.  But you never know that the client is really using the wrong
>> version.  So what happens when there is a serious security problem in a
>> version and you need to upgrade or disable certain clients?  Then you
>> don't know for sure what version each client is running.
>>
>> For the security reason alone, you need to know for sure what software
>> the client is running.  If the client always tells you its version, the
>> server ALWAYS knows what to do.   Otherwise, it's hit or miss.
>>
>> Granted, I haven't been "into" protocols for many, many years.  But this
>> seems like fundamental stuff.   Feel free to talk me down.
>>> On Thu, Mar 2, 2017 at 8:28 PM, Bill Burke <bburke at redhat.com> wrote:
>>>> Add switch IMO.  It should have a select box that defaults to "latest".
>>>>
>>>>
>>>> On 3/2/17 9:44 AM, Marek Posolda wrote:
>>>>> It looks that we should support latest Keycloak server with older
>>>>> versions of Keycloak adapters.
>>>>>
>>>>> So for some corner scenarios, I wonder if we should add the switch to
>>>>> the ClientModel and admin console like "Adapter version" . This switch
>>>>> will be available for both OIDC and SAML clients, but will be useful
>>>>> just for the clients, which uses Keycloak adapter. It will be useful to
>>>>> specify the version of Keycloak client adapter, which particular client
>>>>> application is using. WDYT?
>>>>>
>>>>> The reason why I felt into this is a reported RHSSO bug.
>>>>>
>>>>> Long-story short: When Keycloak SAML 1.9.8 adapter is used with
>>>>> "isPassive=true", then Keycloak 2.5.4 server returns him the valid error
>>>>> response. However 1.9.8 adapter has a bug
>>>>> https://issues.jboss.org/browse/KEYCLOAK-4264 and it throws NPE when it
>>>>> receives such response.
>>>>>
>>>>> With SAML 1.9.8 adapter + 1.9.8 server, the Keycloak server returned
>>>>> invalid error response, however 1.9.8 adapter was able to handle this
>>>>> invalid response without throwing any exception.
>>>>>
>>>>>
>>>>> By adding the switch to the ClientModel, we defacto allow adapter to
>>>>> say: "Please return me broken response, because I am not able to handle
>>>>> valid response."
>>>>>
>>>>> Note that this is bug in adapter, so it will be better to ask customers
>>>>> to rather upgrade their SAML adapters to newest version. On the other
>>>>> hand, we claim to support backwards compatibility.
>>>>>
>>>>> So should we add the switch or not? WDYT?
>>>>>
>>>>> Marek
>>>>>
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> 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