[keycloak-dev] questions on Marek/Hynek presentation

Fri May 19 13:22:58 EDT 2017

On 19/05/17 19:20, Marek Posolda wrote:
> 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.
I meant "restart correct client-context", so you will be authenticated 
to correct client with correct "state" parameter etc.


>
> 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
>
>