[keycloak-dev] questions on Marek/Hynek presentation

Fri May 19 13:20:54 EDT 2017

On 19/05/17 17:53, Marek Posolda wrote:
> On 19/05/17 17:40, Bill Burke wrote:
>>
>>
>> On 5/19/17 11:36 AM, Marek Posolda wrote:
>>> On 19/05/17 17:28, Bill Burke wrote:
>>>>
>>>>
>>>> On 5/19/17 11:25 AM, Marek Posolda wrote:
>>>>> On 19/05/17 16:58, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>>>>> * Won't the regular case be that the load balancer generates the
>>>>>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>>>>>> popular and they have both options.
>>>>>>> Yes, that's also what Sebastien Schuster from community mentioned
>>>>>>> in other thread. That's why I've added
>>>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to
>>>>>>> disable Keycloak adding route to the cookie, or sticky request
>>>>>>> based on something different than cookie (eg. path parameter).
>>>>>>>
>>>>>>> However having Keycloak itself to choose the route has one big
>>>>>>> performance advantage, that it can route to the node, who is
>>>>>>> owner of the entry in the infinispan distributed cache. This
>>>>>>> includes also support for rebalance (owner may change when new
>>>>>>> node joins/leaves cluster, then you change route automatically).
>>>>>>> This is what Wildfly is doing for Http sessions too.
>>>>>>>
>>>>>>> We discussed the integration with KeyAffinityService [1], which
>>>>>>> helps with usecase when loadbalancer generates route to the
>>>>>>> cookie. It ensures that generated session ID will be local to
>>>>>>> current node. Hence loadbalancer can use request node as the
>>>>>>> route and session will be local to it. But this doesn't handle
>>>>>>> rebalance, so IMO preferred option is still to let Keycloak to
>>>>>>> append route.
>>>>>>>
>>>>>>> There is also infinispan grouping API I want to look at.
>>>>>>>
>>>>>>> [1]
>>>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>>>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>>>>>> request continue as normal? Or are you calculating the URI on the
>>>>>>>> application to redirect to, if so, why?
>>>>>>> No, this is just link to client base URI, and then new flow can
>>>>>>> be started from the application. ATM authenticationSession may be
>>>>>>> already removed as user logged already in different browser tab
>>>>>>> etc, so there is no flow to continue with.
>>>>>>>
>>>>>>> Currently there is just userSession available and the client
>>>>>>> application used for "Back to application" is the last
>>>>>>> authenticated client in userSession. I am going to improve it and
>>>>>>> use "client_id" parameter in requests, so in case of expired
>>>>>>> session, already authentication session etc, you would always
>>>>>>> know the client from the "client_id" parameter. Details in the
>>>>>>> other ML thread "Provide a Link to go Back to The Application on
>>>>>>> a Timeout" .
>>>>>>>
>>>>>> Why do you need this page?  Why can't you just proceed with the
>>>>>> OIDC/SAML protocol?
>>>>> You mean redirect automatically to the client, which will start new
>>>>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>>>>
>>>>> Yes, in cases like our admin console, it will be better behaviour
>>>>> then showing "You are already logged in" . But that's just because
>>>>> client base URI, (or client redirect URI) are secured URLs and
>>>>> automatically redirects to Keycloak and starts the flow.
>>>>>
>>>>> But in many applications, this is not the case. For example, you
>>>>> have single page JS application on "http://host/js-app", which is
>>>>> itself not secured URL. So after confirm the expired
>>>>> username/password form, you would redirect to the
>>>>> "http://host/js-app", but you won't be authenticated there. This
>>>>> looks like quite confusing behaviour for the user IMO.
>>>>>
>>>>> Showing "You are already logged in" looks like good compromise. In
>>>>> many cases it is just additional splash screen, but at least it
>>>>> don't confuse users in case that client redirect URI are not
>>>>> secured URLs.
>>>>>
>>>> Not following.  Maybe i need to review the presentation again as
>>>> maybe I'm confused when the "already logged in" screen is shown.
>>> Easy to reproduce:
>>> - Go to "http://localhost:8181/auth/admin" in browser tab 1
>>> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here
>>> - Finish login as admin/admin in tab 2. You are logged in admin console
>>> - Go back to tab 1 and try to login as admin/admin again. Now it's
>>> displayed "You are already logged in" .
>>>
>> Why does this happen?  Why can't Keycloak just finish the OIDC
>> protocol?  Is it because you don't want to ignore the
>> username/password screen?
> The authenticationSession doesn't exists. It was already logged-in. Now
> we have single authenticationSession in the browser as it's tracked with
> the cookie. Support for more authentication sessions within browser can
> be done, but will be quite tricky with tracking session by the cookie
> and not sure it worth the effort for the corner cases like this?
Should I go for something like this? We can have more "client-contexts" 
in single authentication session. Each client-context is per browser 
tab. The state of authenticators, executions etc is shared, but 
client-context is unique per browser tab. So will need to reference 
client_context with the query parameter, so authentication session can 
find correct context based on this parameter. Also KC_RESTART cookie can 
be improved to support for multiple clients, so in every browser tab you 
will be able to restart correct authentication session.

This will be another few days of work, but should be fine. I can work on 
it together with KEYCLOAK-4016 (adding client_id parameter).

WDYT?
Marek
>
> Previous behaviour had more clientSessions in different browser tabs. So
> login in 2 tabs was possible, but after login in tab2, it created
> another userSession and overwrite the previous userSession including
> cookies etc. This had other issues like mentioned in this JIRA
> https://issues.jboss.org/browse/KEYCLOAK-4097
>
> Marek
>> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev