[keycloak-dev] Cross-DC and codeToToken request

Tue May 23 14:11:23 EDT 2017

Doesn't that count on the client actually following the redirect? I don't
think most http libraries do that automatically.

On 23 May 2017 at 17:34, Bill Burke <bburke at redhat.com> wrote:

> What about redirection?  client makes code-to-token request and possibly
> gets a 302 and Location header back as response.  Is that better or worse
> than server-to-server request forwarding?
>
>
>
> On 5/23/17 9:36 AM, Schuster Sebastian (INST/ESY1) wrote:
>
>> As long as it is not user claims or other sensitive stuff, I am fine. Is
>> the idea then to perform a redirect to another DC (with a DC-specific DNS
>> name, not sure redirects on token endpoint are covered by the spec) or to
>> have the load balancer of one DC forward directly to another DC (also not
>> sure this is a common approach)?
>>
>> Mit freundlichen Grüßen / Best regards
>>
>>   Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin
>> | GERMANY | www.bosch-si.com
>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>> Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke at redhat.com]
>>> Sent: Dienstag, 23. Mai 2017 15:11
>>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>>> stian at redhat.com
>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> No reason the code couldn't be "smarter" though.  Something simple and
>>> signed
>>> that has balancing/routing information in it.
>>>
>>>
>>> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>
>>>> I would like to argue against 1). Putting token content into the
>>>> authcode kind of
>>>>
>>> changes the flow to be more like the implicit flow.
>>>
>>>> OIDC/OAuth2 offers the code flow especially to protect information in
>>>> the
>>>>
>>> tokens. Some claims could be sensitive and/or personal information
>>>
>>>> and I think they should not be in the code. Furthermore, enforcing the
>>>> single use
>>>>
>>> of codes becomes even harder if they can be exchanged
>>>
>>>> to tokens without looking up state first. Relaxing the one-time
>>>> requirement is
>>>>
>>> clearly against the spec and one should at least try hard to
>>>
>>>> fulfill it IMHO.
>>>>
>>>> Best regards,
>>>> Sebastian
>>>>
>>>> Mit freundlichen Grüßen / Best regards
>>>>
>>>>    Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
>>>> Berlin |
>>>>
>>> GERMANY | www.bosch-si.com
>>>
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>>> Sebastian.Schuster at bosch-
>>>>
>>> si.com
>>>
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>>>> Sent: Montag, 22. Mai 2017 19:30
>>>>> To: Bill Burke <bburke at redhat.com>
>>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>>
>>>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>>>
>>>>>>> Followup on some previous emails I sent this week around sticky
>>>>>>>> sessions and OIDC backchannel requests.
>>>>>>>>
>>>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>>>> participate in same sticky session like the browser request. It may
>>>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>>>> previous email I sent this
>>>>>>>> week) but not everytime. And looks we would need to support the
>>>>>>>> case when it's not possible.
>>>>>>>>
>>>>>>>> I can start with code-to-token request as it's slightly more
>>>>>>>> complicated then the others due to the reasons:
>>>>>>>>
>>>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>>>
>>>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>>>> channel for communication between datacenters for transfer
>>>>>>>> userSession (which I think should be the default due to performance
>>>>>>>> reasons), then this example flow can happen:
>>>>>>>> - user successfully authenticated and userSession was created on
>>>>>>>> DC1.
>>>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>>>> this request is usually sent very quickly after userSession is
>>>>>>>> created.
>>>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>>>> userSession. So this userSession not yet available here.
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>>>> session_state etc. Among other things, this would require some
>>>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>>>> end visible in browser history. IMO this is not big issue, but not
>>>>>>>> 100% sure..
>>>>>>>>
>>>>>>>> Wouldn't the code also become rather big?
>>>>>>>
>>>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>>>> The details should be in the code and token not in the user session.
>>>>>>>
>>>>>> For protocol mappers, the reason why the user session need to be
>>>>>> available is that some component might be storing temporary
>>>>>> information within the session that needs to be mapped to the token.
>>>>>> Any example is a broker login that doesn't want or need to import into
>>>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>>>> eventually we will want import-less brokering where the user is
>>>>>> created within the session and destroyed with the session so we dont'
>>>>>> have to
>>>>>>
>>>>> hit
>>>
>>>> the DB and import.
>>>>> True, so we basically will need to make sure the user session exists
>>>>> and is
>>>>> persisted. I reckon on-demand replication if technically possible the
>>>>> best
>>>>>
>>>> option.
>>>
>>>>
>>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>>>> userSession is available. Then we would need support for
>>>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>>>> issue and potential for DoS? Still even with asynchronous, the
>>>>>>>> request
>>>>>>>>
>>>>>>> times
>>>
>>>> can be quite long.
>>>>>
>>>>>> I like this option. Could we combine this with on demand replication?
>>>>>>>
>>>>>> With
>>>>>>
>>>>>>> a configurable timeout this would be nifty IMO.
>>>>>>>
>>>>>>
>>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>>>> itself, so the URL will look like:
>>>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>>>> seem
>>>>>>>>
>>>>>>> to
>>>>>>
>>>>>>> support sticky session based on URL part. But there is also
>>>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>>>>
>>>>>>> May work for some, but I doubt it'll work for everyone.
>>>>>>>
>>>>>> imo, this is something that should be added to the spec.  That the
>>>>>> code contains the callback URI.
>>>>>>
>>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>>>>>>
>>>>>>> already.
>>>>>
>>>>>> Not good for performance..
>>>>>>>>
>>>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>>>>
>>>>>> latter
>>>>>>
>>>>>>> may be another issue in cross-DC?
>>>>>>>
>>>>>>>
>>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>>>> Marek
>>>>>>>>
>>>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>>>
>>>>>> Bill
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>