The way a protocol usually implements this is not for the server to keep
track of versions. Rather, the client simply transmits his version as
part of the protocol. Then the server knows what he is dealing with and
acts accordingly.
Also, this has the advantage of allowing automatic auditing of client
versions without manually setting things up from the server side.
On 3/2/2017 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev