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(a)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(a)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@redhat.com]
>> Sent: Dienstag, 23. Mai 2017 15:11
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
>> stian(a)redhat.com
>> Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke(a)redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>>
>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>
>>>>>> On 19 May 2017 at 10:24, Marek Posolda
<mposolda(a)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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>