[keycloak-dev] direct exchanges

[Bill Burke]

Its part of token exchange.  It is committed. (and tested).

On Fri, Sep 15, 2017 at 3:26 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I'm not quite following if you are planning this as part of the token
> exchange services or a new alternative direct grant flow?
>
> On 14 September 2017 at 16:56, Bill Burke <bburke at redhat.com> wrote:
>>
>> I 100% agree that direct/custom grant is not the best way to do it.
>> The question is, is it something we should provide as an *additional*
>> exchange feature?  I think yes.  The way I plan to secure it is as
>> follows:
>>
>> * client must be confidential and be secured by a secret or some other
>> mechanism configured for that client
>> * client must have permission to exchange tokens for target client
>> * client must have permission to impersonate users
>> * user must be impersonateable.
>>
>>
>> On Thu, Sep 14, 2017 at 3:04 AM, Schuster Sebastian (INST/ESY1)
>> <Sebastian.Schuster at bosch-si.com> wrote:
>> > While I do understand the reasons for introducing this feature. I am not
>> > convinced a custom grant is the best way to do it. Wouldn't it be better to
>> > expect that any external mechanism has some way of proving a user has been
>> > authenticated and only being able to get an access token in exchange for
>> > that proof (e.g. ID Token, Assertion, whatever). That's more in line with
>> > the current standardization efforts on token exchange...
>> >
>> > Best regards,
>> > Sebastian
>> >
>> > Mit freundlichen Grüßen / Best regards
>> >
>> > Dr.-Ing.  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
>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; 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 Bill Burke
>> > Sent: Mittwoch, 13. September 2017 16:52
>> > To: keycloak-dev <keycloak-dev at lists.jboss.org>
>> > Subject: [keycloak-dev] direct exchanges
>> >
>> > We have direct grants where client passes username and creds to obtain a
>> > token for that user.  We have client credentials grant to get a token for
>> > the client itself.
>> >
>> > What if we had a direct exchange where the client provides  user id or
>> > username and gets a token for that user?  The client does not have to
>> > provide user credentials.
>> >
>> > What is the use case for this?  Consider an application that is
>> > authenticated via an external mechanism.  Consider that this external
>> > mechanism does not provide any type of token, it just authenticates a
>> > username.  This application needs to talk to services secured by Keycloak.
>> > So, with this new direct exchange mechanism, the application only needs to
>> > have a client account on the Keycloak server
>> > to obtain a token for a keycloak user.   Another benefit of this is
>> > that Keycloak does not need to understand external token formats in
>> > order to provide a token to a client that authenticates users by an external
>> > mechanism.
>> >
>> > There's some big security risks for this.  If the client's secret is
>> > stolen the attacker would be able to mint token for any user.   This
>> > is somewhat mitigated in two ways:
>> >
>> > a) If the token is minted for the client, the scope of the token can be
>> > limited, i.e. role mappings limited
>> >
>> > b) if the client is asking for a different audience (a different
>> > client) the client can be limited on the audience it can ask for.  (we
>> > already do this check for client to client token exchange).
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> > _______________________________________________
>> > 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
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat