9:27 p.m.
Maybe we can solve this somehow too. The iframes can be visible by
default and we can hide them through the javascript, once the document
is loaded. If javascript is disabled, iframe will be still visible, so
user can manually click on logout button. But not sure how bad this is
for usability?
My hope is, if we can remove redirect-based approach and rely on iframes
instead, which will help with cross-dc. But I may miss some corner
cases... If we need to keep the redirect-based approach, we would need
to refactor it anyway IMO as currently frontchannel logout with
redirect-based approach needs to write multiple times to userSession
before it removes it, which is not ideal behaviour. Probably we can
create temporary authenticationSession, which will exist just during the
logout process, and will be able to rely on browser sticky session
between redirects.
Marek
On 03/05/17 15:43, Hynek Mlnarik wrote:
I like this idea.
My only technical concern is whether we need to support browsers with
disabled Javascript - if yes, front channel logouts POST binding might
not work, and we would have to make this optimization optional, e.g.
in realm settings. Currently, POST binding has a fallback for
non-javascript browsers: the user can click a button to submit the
form with logout response manually. This button would not be visible
in an iframe, meaning that the logout would not proceed for that
particular client.
Given that non-Javascript-capable browsers are rather rare, I don't
see this as a blocker so I would prefer going on with Marek's
suggestion and document this as a known limitation.
--Hynek
On Wed, May 3, 2017 at 3:23 PM, Bill Burke <bburke(a)redhat.com> wrote:
>
> On 5/3/17 3:47 AM, Marek Posolda wrote:
>> I went through the OIDC frontchannel logout specification draft [1] and
>> realized that it relies a lot on the iframes instead of browser
>> redirection. Basically OP would render HTML page with the hidden iframes
>> containing the logout URL of clients like:
>>
>> <iframe src="frontchannel_logout_uri">
>>
>> I wonder if we should add some support for the iframes based approach
>> for SAML too? It looks that many vendors including shibboleth (see [2])
>> are using it as it seem to have lots of advantages over the redirection
>> based. Like:
>>
>> - More reliable. With the redirection based approach used by SAML, the
>> IDP needs to redirect browser to the client1, which then need to
>> redirect back to IDP, which continues with redirection to client2 etc.
>> Problem is, that if any client is broken, then whole flow will break and
>> logout won't be finished properly.
>>
>> - Better performance. Logout requests would be sent concurrently to all
>> the clients.
>>
>> - Better for cross-dc as there is no need for more writes to userSession
>> cache. IDP would just render the html with iframes in single request and
>> then remove userSession entirely.
>>
>> Possible disadvantages:
>> - iframes may be blocked on the SP side.
>>
>> - It will require some javascript though as for SAML-SP initiated
>> logout, the IDP needs to send the LogoutResponse back to the SP, which
>> initiated logout. Which means that once HTML with iframes is rendered
>> and all the iframe requests are finished, there would need to be some
>> callback, which will automatically redirect browser back to SP with
>> LogoutResponse.
>>
>> - POST binding for logout. Not sure if this would work with iframes, but
>> I suppose there are some ways how to solve that (automatically submitted
>> form through javascript etc).
> +1, Don't think POSt binding will be an issue. If you look at the POSt
> binding it actually requires HTML forms with embedded Javascript to do a
> "POST redirect".
>
>> - Anything else?
>>
>> WDYT? Do we want to add some support for iframes based logout to our
>> SAML clients?
> What's cool is that logout could be done in parallel, no?
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev