The spec does not mention redirects on the token endpoint, it might cause troubles because
the token issuer does not match the DC-specific DNS name anymore and some people argue
introducing DNS-specific names is a bad idea because people might start using them
directly defeating the original purpose of cross-DC. There's also the issue of library
not following redirects Marek and Stian mentioned. I could imagine server-to-server
forwarding being easier to implement (although it also required DC-specific names) but
performance-wise it is probably inferior to just requesting the session data from the
other DC and answering yourself.
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 |
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 17:34
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
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