4:52 p.m.
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
5:45 p.m.
Hi Bill,
That's definitely something I would like to see appear in Keycloak.
Over the years we've had multiple use cases of system to system
communication, but authenticated "as" the target user to simplify handling
the security on the target endpoints. May happen when you integrate with a
3rd party partner, but want to make the integration seamless to the
end-user, as if the 3rd party system was part of your own. Retrieved token
may either be used by your own backend, or sent to the user's browser for
direct API call on the 3rd party.
With those type of integration, your own backend fully trust the 3rd party
backend and the other way around, at least for some type or operations or
with some restrictions to the endpoints that may be used for integration.
The way you describe this seems like a very reasonable approach. I like the
use of the /token endpoint with a different grant type, rather than
creating a custom endpoint for that purpose. One Login offers such
functionality, but using custom API. We also have other partners offering
this, but again through custom APIs.
We are currently using client credentials authentication for external
systems talking to us. We have the client representing our application
(Bearer Only) and we create different clients for different external
systems so they can authenticate using Client Credentials (system account).
When they hit our REST endpoints with the obtained token, we know exactly
what external system hit which endpoint and the correct roles are assigned
for the operation.
With a similar setup, an external system would be able to obtain a token as
a realm user instead, to allow its use to hit our REST endpoint. we should
be able to know from the token itself which client was used to obtain the
token, which user is being impersonated and what are the roles he has
access to for the bearer only client. I think your point a) and b) cover
that.
Regarding stolen client credentials, this is always a concern. We've
implemented tooling to allow easy reset of them if we believe it has been
stolen. Not worse than using x509 certificates to authenticate an external
system and having the private key stolen.
Gabriel
2017-09-13 10:52 GMT-04:00 Bill Burke <bburke(a)redhat.com>:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Gabriel Lavoie
glavoie(a)gmail.com
9:04 a.m.
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Mittwoch, 13. September 2017 16:52
To: keycloak-dev <keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:56 p.m.
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(a)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(a)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(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Mittwoch, 13. September 2017 16:52
To: keycloak-dev <keycloak-dev(a)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(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
--
Bill Burke
Red Hat
9:26 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org [mailto:keycloak-dev-bounces@
lists.jboss.org] On Behalf Of Bill Burke
> Sent: Mittwoch, 13. September 2017 16:52
> To: keycloak-dev <keycloak-dev(a)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(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
--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:28 p.m.
Its part of token exchange. It is committed. (and tested).
On Fri, Sep 15, 2017 at 3:26 AM, Stian Thorgersen <sthorger(a)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(a)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(a)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(a)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(a)lists.jboss.org
> > [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Bill Burke
> > Sent: Mittwoch, 13. September 2017 16:52
> > To: keycloak-dev <keycloak-dev(a)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(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
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat
2663
days inactive
2670
days old
5 comments
4 participants
participants (4)
-
Bill Burke -
Gabriel Lavoie -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen