[keycloak-dev] questions on Marek/Hynek presentation
Bill Burke
bburke at redhat.com
Fri May 19 11:40:06 EDT 2017
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?
Bill
More information about the keycloak-dev
mailing list