IdP-initiated SSO [1] is a part of SAML 2.0 standard and basically
sends a login response from server (IdP) to client (SP) without client
requesting it. Even though there is no handshake, the client has to
handle it properly. In this particular case, client never scenario to
the server so the server needs to be "told" the version of client
explicitly.
--Hynek
[1]
SSO: POST Binding|outline
On Fri, Mar 3, 2017 at 3:11 PM, Stan Silvert <ssilvert(a)redhat.com> 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(a)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(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
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev