[keycloak-dev] Client adapters backwards compatibility

[Bill Burke]

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.

* As Hynek said, for SAML IDP initiated SSO, there is no client 
request.  User logs in then assertion is sent to client.

* 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.

* Client templates can be used to manage large sets of clients.



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