[keycloak-dev] Client adapters backwards compatibility
bburke at redhat.com
Fri Mar 3 09:35:01 EST 2017
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?
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
More information about the keycloak-dev