[keycloak-dev] Cross-DC and codeToToken request

Wed May 24 03:06:15 EDT 2017

ah yes. We want to avoid writing details into userSession everytime when 
the same client do SSO login again (like browser refresh of javascript 
application page etc). Yep, so looks that code also needs to contain 
stuff like client_id, scope and others besides userSession.

Marek

On 23/05/17 20:11, Stian Thorgersen wrote:
> Doesn't the code only have to contain client_id, scope, etc.? Then the
> protocol mappers can be evaluated when the token is generated rather than
> when the code is generated?
>
> On 23 May 2017 at 15:11, Bill Burke <bburke at redhat.com> wrote:
>
>> 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
>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev