[keycloak-dev] Frontchannel logout based on iframes?

[Marek Posolda]

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>