8:37 a.m.
Hi,
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses
the term “client scope” to determine what the OAuth client wants to do with the granted
access (e.g. this could be used to determine the purpose of processing some data for GDPR
compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might
lead to some confusion. As you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
3 p.m.
I need to take a closer look on what Marek did around client scopes. So
far, scopes were basically associated with roles and protocol mappers and
that is not really what we need in UMA 2.0.
If scopes now is more abstract and we can remove "authorization scopes" in
authz services, I need to take a look ...
In fact, I need to review scope parameter in UMA grant type in order to
allow clients to push additional scopes other those already added in a
ticket.
On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi,
I saw there are activities to replace client templates with client scopes.
UMA 2.0 uses the term “client scope” to determine what the OAuth client
wants to do with the granted access (e.g. this could be used to determine
the purpose of processing some data for GDPR compliance). Since Keycloak
will also support UMA 2.0, I am a little concerned this might lead to some
confusion. As you know, there are only two hard problems in computer
science: cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:03 p.m.
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
Hi,
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses
the term “client scope” to determine what the OAuth client wants to do with the granted
access (e.g. this could be used to determine the purpose of processing some data for GDPR
compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might
lead to some confusion. As you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:39 a.m.
How a scope looks like now after your changes ? Are they just strings
referencing a set of one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
That's good question. As you know, we also have "Scope"
tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to replace client templates with client
scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
client wants to do with the granted access (e.g. this could be used to
determine the purpose of processing some data for GDPR compliance). Since
Keycloak will also support UMA 2.0, I am a little concerned this might lead
to some confusion. As you know, there are only two hard problems in
computer science: cache invalidation, naming things, and off-by-one errors.
☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr. Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> 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
7:11 a.m.
I just checked the UMA 2.0 spec again and I found that the term “client scope” is not used
directly. It is just called scope but associated to the client and not the resource
server,
See section 3.3.1 Client Request to Authorization Server for RPT in :
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
scope
OPTIONAL. A string of space-separated values representing requested scopes. For the
authorization server to consider any requested scope in its assessment, the client MUST
have been pre-registered for the same scope with the authorization server. The client
should consult the resource server's API documentation for details about which scopes
it can expect the resource server's initial returned permission ticket to represent as
part of the authorization assessment (see Section 3.3.4).
The resource server has its own set of scopes that is also used assess authorizations, see
section 3.3.4 Authorization Assessment and Results Determination.
I just fear the term „scope“ is a bit overused…
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: Mittwoch, 14. März 2018 21:01
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Client Scope naming
I need to take a closer look on what Marek did around client scopes. So far, scopes were
basically associated with roles and protocol mappers and that is not really what we need
in UMA 2.0.
If scopes now is more abstract and we can remove "authorization scopes" in authz
services, I need to take a look ...
In fact, I need to review scope parameter in UMA grant type in order to allow clients to
push additional scopes other those already added in a ticket.
On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
Hi,
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses
the term “client scope” to determine what the OAuth client wants to do with the granted
access (e.g. this could be used to determine the purpose of processing some data for GDPR
compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might
lead to some confusion. As you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:21 a.m.
It is a pertinent concern. That scope parameters is something clients can
use to ask for additional scopes after receiving a ticket (with can already
some scopes defined by the RS). Right now the resource server is
responsible for defining these scopes.
The thing is that scopes in authz services can be anything and they don't
really represent a access context. For instance, scopes can be actions you
can perform on a resource, information about a resource, etc.
I just checked UMA 2.0 grant type implementation and we are already
considering any addition scope defined by the client using the "scope"
parameter.
On Thu, Mar 15, 2018 at 9:11 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
I just checked the UMA 2.0 spec again and I found that the term
“client
scope” is not used directly. It is just called scope but associated to the
client and not the resource server,
See section 3.3.1 Client Request to Authorization Server for RPT in :
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
scope
OPTIONAL. A string of space-separated values representing requested
scopes. For the authorization server to consider any requested scope in its
assessment, the client MUST have been pre-registered for the same scope
with the authorization server. The client should consult the resource
server's API documentation for details about which scopes it can expect the
resource server's initial returned permission ticket to represent as part
of the authorization assessment (see Section 3.3.4).
The resource server has its own set of scopes that is also used assess
authorizations, see section 3.3.4 Authorization Assessment and Results
Determination.
I just fear the term „scope“ is a bit overused…
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
*Dr.-Ing. Sebastian Schuster *
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100
<+49%2030%20726112100> | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
*From:* Pedro Igor Silva [mailto:psilva@redhat.com]
*Sent:* Mittwoch, 14. März 2018 21:01
*To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
*Cc:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* Re: [keycloak-dev] Client Scope naming
I need to take a closer look on what Marek did around client scopes. So
far, scopes were basically associated with roles and protocol mappers and
that is not really what we need in UMA 2.0.
If scopes now is more abstract and we can remove "authorization scopes" in
authz services, I need to take a look ...
In fact, I need to review scope parameter in UMA grant type in order to
allow clients to push additional scopes other those already added in a
ticket.
On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi,
I saw there are activities to replace client templates with client scopes.
UMA 2.0 uses the term “client scope” to determine what the OAuth client
wants to do with the granted access (e.g. this could be used to determine
the purpose of processing some data for GDPR compliance). Since Keycloak
will also support UMA 2.0, I am a little concerned this might lead to some
confusion. As you know, there are only two hard problems in computer
science: cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:46 a.m.
Scope parameter would reference client scopes. For example scope
parameter "openid email profile offline_access" will reference client
scopes "email", "profile" and "offline_access" (openid is
jsut generic
OpenID Connect marker). And each client scope is set of protocolMappers
and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings
referencing a set of one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope",
which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to replace client templates with
client scopes. UMA 2.0 uses the term “client scope” to determine
what the OAuth client wants to do with the granted access (e.g.
this could be used to determine the purpose of processing some
data for GDPR compliance). Since Keycloak will also support UMA
2.0, I am a little concerned this might lead to some confusion. As
you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
Berlin | GERMANY | www.bosch-si.com
<http://www.bosch-si.com><http://www.bosch-si.com
<http://www.bosch-si.com>>
> Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax +49
30 726112-100 <tel:%2B49%2030%20726112-100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
7:24 a.m.
That is what I was thinking. In authz services, scopes are not related with
roles or protocol mappers. They are just a string representing something
you can perform/access in a protected resource. Use client scopes to
represent such concept and remove "authz scopes" tab is a bit overkill, I
think.
Currently, if I have a Localization API and a scope that grants access
based on a "device.localization" scope, I would need to create a
role/mapper and associate it with a client scope, right ?
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
Scope parameter would reference client scopes. For example scope
parameter
"openid email profile offline_access" will reference client scopes
"email",
"profile" and "offline_access" (openid is jsut generic OpenID
Connect
marker). And each client scope is set of protocolMappers and/or Role scope
mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings
referencing a set of one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com>
wrote:
> That's good question. As you know, we also have "Scope" tab (used to
> specify scope role mappings of client) and "Authorization scope", which
> is used when Authorization is enabled :)
>
> Marek
>
> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> > Hi,
> >
> > I saw there are activities to replace client templates with client
> scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
> client wants to do with the granted access (e.g. this could be used to
> determine the purpose of processing some data for GDPR compliance). Since
> Keycloak will also support UMA 2.0, I am a little concerned this might lead
> to some confusion. As you know, there are only two hard problems in
> computer science: cache invalidation, naming things, and off-by-one errors.
> ☺ WDYT?
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Dr.-Ing. Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30
> 726112-100 <%2B49%2030%20726112-100> | Sebastian.Schuster(a)bosch-si.com
> <mailto:Sebastian.Schuster@bosch-si.com>
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr. Stefan Ferber, Michael Hahn
> >
> >
> >
> > _______________________________________________
> > 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
>
8:12 a.m.
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not
related
with roles or protocol mappers. They are just a string representing
something you can perform/access in a protected resource. Use client
scopes to represent such concept and remove "authz scopes" tab is a
bit overkill, I think.
Currently, if I have a Localization API and a scope that grants access
based on a "device.localization" scope, I would need to create a
role/mapper and associate it with a client scope, right ?
You mean that you have
support for "device.localization" value of OAuth
scope parameter? Yes, you would need to create clientScope and associate
role "device.localization" with it. With client scopes support, the
scope parameter doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Scope parameter would reference client scopes. For example scope
parameter "openid email profile offline_access" will reference
client scopes "email", "profile" and "offline_access"
(openid is
jsut generic OpenID Connect marker). And each client scope is set
of protocolMappers and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
> How a scope looks like now after your changes ? Are they just
> strings referencing a set of one or more roles ? Or they are
> still roles ?
>
> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>
> That's good question. As you know, we also have "Scope" tab
> (used to
> specify scope role mappings of client) and "Authorization
> scope", which
> is used when Authorization is enabled :)
>
> Marek
>
> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> > Hi,
> >
> > I saw there are activities to replace client templates with
> client scopes. UMA 2.0 uses the term “client scope” to
> determine what the OAuth client wants to do with the granted
> access (e.g. this could be used to determine the purpose of
> processing some data for GDPR compliance). Since Keycloak
> will also support UMA 2.0, I am a little concerned this might
> lead to some confusion. As you know, there are only two hard
> problems in computer science: cache invalidation, naming
> things, and off-by-one errors. ☺ WDYT?
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Dr.-Ing. Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
> Berlin | GERMANY | www.bosch-si.com
> <http://www.bosch-si.com><http://www.bosch-si.com
> <http://www.bosch-si.com>>
> > Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax
> +49 30 726112-100 <tel:%2B49%2030%20726112-100> |
> Sebastian.Schuster(a)bosch-si.com
>
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
> <mailto:Sebastian.Schuster@bosch-si.com>>
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg;
> HRB 148411 B
> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
> Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
8:27 a.m.
We already had discussions a long time ago about it. I do think that scopes
are a first class citizen when doing OIDC and OAuth2, not RBAC. We are too
role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the
token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented to
grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not related
with roles or protocol mappers. They are just a string representing
something you can perform/access in a protected resource. Use client scopes
to represent such concept and remove "authz scopes" tab is a bit overkill,
I think.
Currently, if I have a Localization API and a scope that grants access
based on a "device.localization" scope, I would need to create a
role/mapper and associate it with a client scope, right ?
You mean that you have support for "device.localization" value of OAuth
scope parameter? Yes, you would need to create clientScope and associate
role "device.localization" with it. With client scopes support, the scope
parameter doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com>
wrote:
> Scope parameter would reference client scopes. For example scope
> parameter "openid email profile offline_access" will reference client
> scopes "email", "profile" and "offline_access" (openid
is jsut generic
> OpenID Connect marker). And each client scope is set of protocolMappers
> and/or Role scope mappings.
>
> Marek
>
>
> On 15/03/18 12:39, Pedro Igor Silva wrote:
>
> How a scope looks like now after your changes ? Are they just strings
> referencing a set of one or more roles ? Or they are still roles ?
>
> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
>> That's good question. As you know, we also have "Scope" tab (used
to
>> specify scope role mappings of client) and "Authorization scope",
which
>> is used when Authorization is enabled :)
>>
>> Marek
>>
>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
>> > Hi,
>> >
>> > I saw there are activities to replace client templates with client
>> scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
>> client wants to do with the granted access (e.g. this could be used to
>> determine the purpose of processing some data for GDPR compliance). Since
>> Keycloak will also support UMA 2.0, I am a little concerned this might lead
>> to some confusion. As you know, there are only two hard problems in
>> computer science: cache invalidation, naming things, and off-by-one errors.
>> ☺ WDYT?
>> >
>> > Best regards,
>> > Sebastian
>> >
>> > Mit freundlichen Grüßen / Best regards
>> >
>> > Dr.-Ing. Sebastian Schuster
>> >
>> > Engineering and Support (INST/ESY1)
>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
>> GERMANY
>>
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
>> | www.bosch-si.com<http://www.bosch-si.com>
>> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>> Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
>> >
>> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
>> Dr. Stefan Ferber, Michael Hahn
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
>
3:22 a.m.
Yes, and this (almost) all should be possible now with new client scopes
stuff I did. It won't be a problem to have "device.localization" client
scope, which doesn't have any roles or protocolMappers. And require this
client scope to be present on consent screen.
Only thing, which is not directly available OOTB from what you
mentioned, is the: Check if scope "device.localization" is granted by
introspecting the token. For instance, checking a scope claim within a
token.
For now, I've just added client scopes to refresh token, but that one is
opaque to the adapter. I did not add anything to access token or ID
token. The "scope" claim is not defined on OIDC or OAuth2, so we don't
have it in our tokens. Do you know if it's defined in some other
specification? We can do our extension and add some stuff into access
token similarly like we did for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that
scopes are a first class citizen when doing OIDC and OAuth2, not RBAC.
We are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the
token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just
consented to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
> That is what I was thinking. In authz services, scopes are not
> related with roles or protocol mappers. They are just a string
> representing something you can perform/access in a protected
> resource. Use client scopes to represent such concept and remove
> "authz scopes" tab is a bit overkill, I think.
>
> Currently, if I have a Localization API and a scope that grants
> access based on a "device.localization" scope, I would need to
> create a role/mapper and associate it with a client scope, right ?
You mean that you have support for "device.localization" value of
OAuth scope parameter? Yes, you would need to create clientScope
and associate role "device.localization" with it. With client
scopes support, the scope parameter doesn't reference single role,
but single client scope.
Marek
>
> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>
> Scope parameter would reference client scopes. For example
> scope parameter "openid email profile offline_access" will
> reference client scopes "email", "profile" and
> "offline_access" (openid is jsut generic OpenID Connect
> marker). And each client scope is set of protocolMappers
> and/or Role scope mappings.
>
> Marek
>
>
> On 15/03/18 12:39, Pedro Igor Silva wrote:
>> How a scope looks like now after your changes ? Are they
>> just strings referencing a set of one or more roles ? Or
>> they are still roles ?
>>
>> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
>> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>>
>> That's good question. As you know, we also have
"Scope"
>> tab (used to
>> specify scope role mappings of client) and
>> "Authorization scope", which
>> is used when Authorization is enabled :)
>>
>> Marek
>>
>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
>> > Hi,
>> >
>> > I saw there are activities to replace client templates
>> with client scopes. UMA 2.0 uses the term “client scope”
>> to determine what the OAuth client wants to do with the
>> granted access (e.g. this could be used to determine the
>> purpose of processing some data for GDPR compliance).
>> Since Keycloak will also support UMA 2.0, I am a little
>> concerned this might lead to some confusion. As you
>> know, there are only two hard problems in computer
>> science: cache invalidation, naming things, and
>> off-by-one errors. ☺ WDYT?
>> >
>> > Best regards,
>> > Sebastian
>> >
>> > Mit freundlichen Grüßen / Best regards
>> >
>> > Dr.-Ing. Sebastian Schuster
>> >
>> > Engineering and Support (INST/ESY1)
>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 |
>> 12109 Berlin | GERMANY
>>
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
>> | www.bosch-si.com
>> <http://www.bosch-si.com><http://www.bosch-si.com
>> <http://www.bosch-si.com>>
>> > Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> |
>> Fax +49 30 726112-100 <tel:%2B49%2030%20726112-100> |
>> Sebastian.Schuster(a)bosch-si.com
>>
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
>> <mailto:Sebastian.Schuster@bosch-si.com>>
>> >
>> > Sitz: Berlin, Registergericht: Amtsgericht
>> Charlottenburg; HRB 148411 B
>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
>> Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
>> >
>> >
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
7:18 a.m.
OAuth2 does not define any format for access tokens - as you know they are
opaque - so you can push whatever you want into it, use it as a reference,
etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that
token introspection response includes a "scope" claim.
The main point I'm trying to make here is that access tokens usually
represent user consent. Consent is not the same thing as a role granted to
an user. So I may want to build my REST API without any role mapping but
based on user consent to specific scopes. Where these scopes grant access
to different parts of my API.
But I think that should also be possible with your changes. We would just
need to have a mapper that adds to an access token the scopes granted by
the user to a client. Or maybe make this information also available via
introspection endpoint (which I think we are missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
Yes, and this (almost) all should be possible now with new client
scopes
stuff I did. It won't be a problem to have "device.localization" client
scope, which doesn't have any roles or protocolMappers. And require this
client scope to be present on consent screen.
Only thing, which is not directly available OOTB from what you mentioned,
is the: Check if scope "device.localization" is granted by introspecting
the token. For instance, checking a scope claim within a token.
For now, I've just added client scopes to refresh token, but that one is
opaque to the adapter. I did not add anything to access token or ID token.
The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in
our tokens. Do you know if it's defined in some other specification? We can
do our extension and add some stuff into access token similarly like we did
for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that
scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the
token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented
to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com>
wrote:
> On 16/03/18 13:24, Pedro Igor Silva wrote:
>
> That is what I was thinking. In authz services, scopes are not related
> with roles or protocol mappers. They are just a string representing
> something you can perform/access in a protected resource. Use client scopes
> to represent such concept and remove "authz scopes" tab is a bit overkill,
> I think.
>
> Currently, if I have a Localization API and a scope that grants access
> based on a "device.localization" scope, I would need to create a
> role/mapper and associate it with a client scope, right ?
>
> You mean that you have support for "device.localization" value of OAuth
> scope parameter? Yes, you would need to create clientScope and associate
> role "device.localization" with it. With client scopes support, the scope
> parameter doesn't reference single role, but single client scope.
>
> Marek
>
>
> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
>> Scope parameter would reference client scopes. For example scope
>> parameter "openid email profile offline_access" will reference client
>> scopes "email", "profile" and "offline_access"
(openid is jsut generic
>> OpenID Connect marker). And each client scope is set of protocolMappers
>> and/or Role scope mappings.
>>
>> Marek
>>
>>
>> On 15/03/18 12:39, Pedro Igor Silva wrote:
>>
>> How a scope looks like now after your changes ? Are they just strings
>> referencing a set of one or more roles ? Or they are still roles ?
>>
>> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com>
>> wrote:
>>
>>> That's good question. As you know, we also have "Scope" tab
(used to
>>> specify scope role mappings of client) and "Authorization scope",
which
>>> is used when Authorization is enabled :)
>>>
>>> Marek
>>>
>>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
>>> > Hi,
>>> >
>>> > I saw there are activities to replace client templates with client
>>> scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
>>> client wants to do with the granted access (e.g. this could be used to
>>> determine the purpose of processing some data for GDPR compliance). Since
>>> Keycloak will also support UMA 2.0, I am a little concerned this might lead
>>> to some confusion. As you know, there are only two hard problems in
>>> computer science: cache invalidation, naming things, and off-by-one errors.
>>> ☺ WDYT?
>>> >
>>> > Best regards,
>>> > Sebastian
>>> >
>>> > Mit freundlichen Grüßen / Best regards
>>> >
>>> > Dr.-Ing. Sebastian Schuster
>>> >
>>> > Engineering and Support (INST/ESY1)
>>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
>>> GERMANY
>>>
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
>>> | www.bosch-si.com<http://www.bosch-si.com>
>>> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30
>>> 726112-100 <%2B49%2030%20726112-100> | Sebastian.Schuster(a)bosch-si.com
>>> <mailto:Sebastian.Schuster@bosch-si.com>
>>> >
>>> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>>> B
>>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
>>> Dr. Stefan Ferber, Michael Hahn
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>>
>
>
7:33 a.m.
If you support scopes you definitely need some claims in the token that represent the
granted scopes. Otherwise as a resource server you could only do token introspection to
retrieve the scopes and having to do this always defeats the purpose of self-contained
tokens. The fact that Keycloak supports defining custom mappings of scopes to roles (and
now arbitrary claims with token mappers) is just fine, I think.
Btw. access tokens and scopes is not always user consent, see client credentials grant…
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: Montag, 19. März 2018 13:19
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know they are opaque - so you
can push whatever you want into it, use it as a reference, etc. But if you look
https://tools.ietf.org/html/rfc7662 you'll see that token introspection response
includes a "scope" claim.
The main point I'm trying to make here is that access tokens usually represent user
consent. Consent is not the same thing as a role granted to an user. So I may want to
build my REST API without any role mapping but based on user consent to specific scopes.
Where these scopes grant access to different parts of my API.
But I think that should also be possible with your changes. We would just need to have a
mapper that adds to an access token the scopes granted by the user to a client. Or maybe
make this information also available via introspection endpoint (which I think we are
missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Yes, and this (almost) all should be possible now with new client scopes stuff I did. It
won't be a problem to have "device.localization" client scope, which
doesn't have any roles or protocolMappers. And require this client scope to be present
on consent screen.
Only thing, which is not directly available OOTB from what you mentioned, is the: Check if
scope "device.localization" is granted by introspecting the token. For instance,
checking a scope claim within a token.
For now, I've just added client scopes to refresh token, but that one is opaque to the
adapter. I did not add anything to access token or ID token. The "scope" claim
is not defined on OIDC or OAuth2, so we don't have it in our tokens. Do you know if
it's defined in some other specification? We can do our extension and add some stuff
into access token similarly like we did for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that scopes are a first
class citizen when doing OIDC and OAuth2, not RBAC. We are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the token.
For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented to grant
"device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not related with roles or
protocol mappers. They are just a string representing something you can perform/access in
a protected resource. Use client scopes to represent such concept and remove "authz
scopes" tab is a bit overkill, I think.
Currently, if I have a Localization API and a scope that grants access based on a
"device.localization" scope, I would need to create a role/mapper and associate
it with a client scope, right ?
You mean that you have support for "device.localization" value of OAuth scope
parameter? Yes, you would need to create clientScope and associate role
"device.localization" with it. With client scopes support, the scope parameter
doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Scope parameter would reference client scopes. For example scope parameter "openid
email profile offline_access" will reference client scopes "email",
"profile" and "offline_access" (openid is jsut generic OpenID Connect
marker). And each client scope is set of protocolMappers and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings referencing a set of
one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
Hi,
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses
the term “client scope” to determine what the OAuth client wants to do with the granted
access (e.g. this could be used to determine the purpose of processing some data for GDPR
compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might
lead to some confusion. As you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%...
| www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:59 a.m.
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
If you support scopes you definitely need some claims in the token
that
represent the granted scopes. Otherwise as a resource server you could only
do token introspection to retrieve the scopes and having to do this always
defeats the purpose of self-contained tokens. The fact that Keycloak
supports defining custom mappings of scopes to roles (and now arbitrary
claims with token mappers) is just fine, I think.
Btw. access tokens and scopes is not always user consent, see client
credentials grant…
Yeah, that is why I said usually. My initial idea was discuss cases where
scopes are *not* limited to the protected resources under the control of
the client.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
*Dr.-Ing. Sebastian Schuster *
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100
<+49%2030%20726112100> | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
*From:* Pedro Igor Silva [mailto:psilva@redhat.com]
*Sent:* Montag, 19. März 2018 13:19
*To:* Marek Posolda <mposolda(a)redhat.com>
*Cc:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Subject:* Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know they are
opaque - so you can push whatever you want into it, use it as a reference,
etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that
token introspection response includes a "scope" claim.
The main point I'm trying to make here is that access tokens usually
represent user consent. Consent is not the same thing as a role granted to
an user. So I may want to build my REST API without any role mapping but
based on user consent to specific scopes. Where these scopes grant access
to different parts of my API.
But I think that should also be possible with your changes. We would just
need to have a mapper that adds to an access token the scopes granted by
the user to a client. Or maybe make this information also available via
introspection endpoint (which I think we are missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda(a)redhat.com>
wrote:
Yes, and this (almost) all should be possible now with new client scopes
stuff I did. It won't be a problem to have "device.localization" client
scope, which doesn't have any roles or protocolMappers. And require this
client scope to be present on consent screen.
Only thing, which is not directly available OOTB from what you mentioned,
is the: Check if scope "device.localization" is granted by introspecting
the token. For instance, checking a scope claim within a token.
For now, I've just added client scopes to refresh token, but that one is
opaque to the adapter. I did not add anything to access token or ID token.
The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in
our tokens. Do you know if it's defined in some other specification? We can
do our extension and add some stuff into access token similarly like we did
for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that
scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the
token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented
to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com>
wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not related
with roles or protocol mappers. They are just a string representing
something you can perform/access in a protected resource. Use client scopes
to represent such concept and remove "authz scopes" tab is a bit overkill,
I think.
Currently, if I have a Localization API and a scope that grants access
based on a "device.localization" scope, I would need to create a
role/mapper and associate it with a client scope, right ?
You mean that you have support for "device.localization" value of OAuth
scope parameter? Yes, you would need to create clientScope and associate
role "device.localization" with it. With client scopes support, the scope
parameter doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com>
wrote:
Scope parameter would reference client scopes. For example scope parameter
"openid email profile offline_access" will reference client scopes
"email",
"profile" and "offline_access" (openid is jsut generic OpenID
Connect
marker). And each client scope is set of protocolMappers and/or Role scope
mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings
referencing a set of one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com>
wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to replace client templates with client
scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
client wants to do with the granted access (e.g. this could be used to
determine the purpose of processing some data for GDPR compliance). Since
Keycloak will also support UMA 2.0, I am a little concerned this might lead
to some confusion. As you know, there are only two hard problems in
computer science: cache invalidation, naming things, and off-by-one errors.
☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
| www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr. Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> 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
12:31 p.m.
I see. I think you guys have very good points. I've created JIRA
https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we
return "scope" in the access token.
With my PR, the "scope" is already returned in the TokenResponse as
defined in the OAuth2 [1] . But Introspection endpoint doesn't return
"scope" because access token doesn't yet have scope in my PR.
I've just added scope information to the refresh token, but I didn't add
scope claim directly. I've added "client-scopes" claim to the refresh
token with the list of UUIDs referencing used client scopes. I did this
just because:
a) refreshToken is opaque to the application and just Keycloak needs to
be able to read it and decode used client scopes from it.
b) referencing by UUID is in theory bit safer instead of referencing by
scope names. I was just thinking about corner case when admin deletes
scope "foo" and then re-create scope "foo" again, it would be
something
different then what user granted, even if it's same name. Hence I used
reference by UUID. But this is probably just corner case, which won't
happen in practice.
When thinking more about it, it seems that none of the points (a) and
(b) justifies this unecessary complication with using "client-scopes"
rather then just "scope". It will be just easier if both access token
and refreshToken contains "scope" claim in the OAuth2 format. WDYT?
[1] https://tools.ietf.org/html/rfc6749#section-5.1
Marek
On 19/03/18 13:59, Pedro Igor Silva wrote:
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>> wrote:
If you support scopes you definitely need some claims in the token
that represent the granted scopes. Otherwise as a resource server
you could only do token introspection to retrieve the scopes and
having to do this always defeats the purpose of self-contained
tokens. The fact that Keycloak supports defining custom mappings
of scopes to roles (and now arbitrary claims with token mappers)
is just fine, I think.
Btw. access tokens and scopes is not always user consent, see
client credentials grant…
Yeah, that is why I said usually. My initial idea was discuss cases
where scopes are *not* limited to the protected resources under the
control of the client.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
*Dr.-Ing. Sebastian Schuster
*
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
|
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
| www.bosch-si.com <http://www.bosch-si.com>
Tel. +49 30 726112-485 <tel:+49%2030%20726112485> | Fax +49 30
726112-100 <tel:+49%2030%20726112100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
*From:*Pedro Igor Silva [mailto:psilva@redhat.com
<mailto:psilva@redhat.com>]
*Sent:* Montag, 19. März 2018 13:19
*To:* Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
*Cc:* Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>; keycloak-dev
<keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>>
*Subject:* Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know
they are opaque - so you can push whatever you want into it, use
it as a reference, etc. But if you look
https://tools.ietf.org/html/rfc7662
<https://tools.ietf.org/html/rfc7662> you'll see that token
introspection response includes a "scope" claim.
The main point I'm trying to make here is that access tokens
usually represent user consent. Consent is not the same thing as a
role granted to an user. So I may want to build my REST API
without any role mapping but based on user consent to specific
scopes. Where these scopes grant access to different parts of my API.
But I think that should also be possible with your changes. We
would just need to have a mapper that adds to an access token the
scopes granted by the user to a client. Or maybe make this
information also available via introspection endpoint (which I
think we are missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda
<mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
Yes, and this (almost) all should be possible now with new
client scopes stuff I did. It won't be a problem to have
"device.localization" client scope, which doesn't have any
roles or protocolMappers. And require this client scope to be
present on consent screen.
Only thing, which is not directly available OOTB from what you
mentioned, is the: Check if scope "device.localization" is
granted by introspecting the token. For instance, checking a
scope claim within a token.
For now, I've just added client scopes to refresh token, but
that one is opaque to the adapter. I did not add anything to
access token or ID token. The "scope" claim is not defined on
OIDC or OAuth2, so we don't have it in our tokens. Do you know
if it's defined in some other specification? We can do our
extension and add some stuff into access token similarly like
we did for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do
think that scopes are a first class citizen when doing
OIDC and OAuth2, not RBAC. We are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent
required for a client
As a client:
* Ask for "device.localization" scope when obtaining
tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by
introspecting the token. For instance, checking a scope
claim within a token.
See, no role mapping, no scope -> role mapping, etc. User
just consented to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda
<mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services,
scopes are not related with roles or protocol
mappers. They are just a string representing
something you can perform/access in a protected
resource. Use client scopes to represent such
concept and remove "authz scopes" tab is a bit
overkill, I think.
Currently, if I have a Localization API and a
scope that grants access based on a
"device.localization" scope, I would need to
create a role/mapper and associate it with a
client scope, right ?
You mean that you have support for
"device.localization" value of OAuth scope parameter?
Yes, you would need to create clientScope and
associate role "device.localization" with it. With
client scopes support, the scope parameter doesn't
reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
<mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
wrote:
Scope parameter would reference client scopes.
For example scope parameter "openid email
profile offline_access" will reference client
scopes "email", "profile" and
"offline_access"
(openid is jsut generic OpenID Connect
marker). And each client scope is set of
protocolMappers and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your
changes ? Are they just strings
referencing a set of one or more roles ?
Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek
Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
That's good question. As you know, we
also have "Scope" tab (used to
specify scope role mappings of client)
and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian
(INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to
replace client templates with client
scopes. UMA 2.0 uses the term “client
scope” to determine what the OAuth
client wants to do with the granted
access (e.g. this could be used to
determine the purpose of processing
some data for GDPR compliance). Since
Keycloak will also support UMA 2.0, I
am a little concerned this might lead
to some confusion. As you know, there
are only two hard problems in computer
science: cache invalidation, naming
things, and off-by-one errors. ☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH |
Ullsteinstr. 128 | 12109 Berlin |
GERMANY
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
| www.bosch-si.com
<http://www.bosch-si.com><http://www.bosch-si.com
<http://www.bosch-si.com>>
> Tel. +49 30 726112-485
<tel:%2B49%2030%20726112-485> | Fax
+49 30 726112-100
<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>
>
> Sitz: Berlin, Registergericht:
Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing.
Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
>
>
>
>
_______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
2:08 p.m.
+1
On Mon, Mar 19, 2018 at 2:31 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
I see. I think you guys have very good points. I've created JIRA
https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return
"scope" in the access token.
With my PR, the "scope" is already returned in the TokenResponse as
defined in the OAuth2 [1] . But Introspection endpoint doesn't return
"scope" because access token doesn't yet have scope in my PR.
I've just added scope information to the refresh token, but I didn't add
scope claim directly. I've added "client-scopes" claim to the refresh
token
with the list of UUIDs referencing used client scopes. I did this just
because:
a) refreshToken is opaque to the application and just Keycloak needs to be
able to read it and decode used client scopes from it.
b) referencing by UUID is in theory bit safer instead of referencing by
scope names. I was just thinking about corner case when admin deletes scope
"foo" and then re-create scope "foo" again, it would be something
different
then what user granted, even if it's same name. Hence I used reference by
UUID. But this is probably just corner case, which won't happen in
practice.
When thinking more about it, it seems that none of the points (a) and (b)
justifies this unecessary complication with using "client-scopes" rather
then just "scope". It will be just easier if both access token and
refreshToken contains "scope" claim in the OAuth2 format. WDYT?
[1] https://tools.ietf.org/html/rfc6749#section-5.1
Marek
On 19/03/18 13:59, Pedro Igor Silva wrote:
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
> If you support scopes you definitely need some claims in the token that
> represent the granted scopes. Otherwise as a resource server you could only
> do token introspection to retrieve the scopes and having to do this always
> defeats the purpose of self-contained tokens. The fact that Keycloak
> supports defining custom mappings of scopes to roles (and now arbitrary
> claims with token mappers) is just fine, I think.
>
>
>
> Btw. access tokens and scopes is not always user consent, see client
> credentials grant…
>
Yeah, that is why I said usually. My initial idea was discuss cases where
scopes are *not* limited to the protected resources under the control of
the client.
>
>
> Best regards,
>
> Sebastian
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dr.-Ing. Sebastian Schuster *
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
>
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100
> <+49%2030%20726112100> | Sebastian.Schuster(a)bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr. Stefan Ferber, Michael Hahn
>
>
>
> *From:* Pedro Igor Silva [mailto:psilva@redhat.com]
> *Sent:* Montag, 19. März 2018 13:19
> *To:* Marek Posolda <mposolda(a)redhat.com>
> *Cc:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
> keycloak-dev <keycloak-dev(a)lists.jboss.org>
> *Subject:* Re: [keycloak-dev] Client Scope naming
>
>
>
> OAuth2 does not define any format for access tokens - as you know they
> are opaque - so you can push whatever you want into it, use it as a
> reference, etc. But if you look https://tools.ietf.org/html/rfc7662
> you'll see that token introspection response includes a "scope" claim.
>
>
>
> The main point I'm trying to make here is that access tokens usually
> represent user consent. Consent is not the same thing as a role granted to
> an user. So I may want to build my REST API without any role mapping but
> based on user consent to specific scopes. Where these scopes grant access
> to different parts of my API.
>
>
>
> But I think that should also be possible with your changes. We would just
> need to have a mapper that adds to an access token the scopes granted by
> the user to a client. Or maybe make this information also available via
> introspection endpoint (which I think we are missing).
>
>
>
> On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
> Yes, and this (almost) all should be possible now with new client scopes
> stuff I did. It won't be a problem to have "device.localization"
client
> scope, which doesn't have any roles or protocolMappers. And require this
> client scope to be present on consent screen.
>
> Only thing, which is not directly available OOTB from what you mentioned,
> is the: Check if scope "device.localization" is granted by introspecting
> the token. For instance, checking a scope claim within a token.
>
> For now, I've just added client scopes to refresh token, but that one is
> opaque to the adapter. I did not add anything to access token or ID token.
> The "scope" claim is not defined on OIDC or OAuth2, so we don't have it
in
> our tokens. Do you know if it's defined in some other specification? We can
> do our extension and add some stuff into access token similarly like we did
> for roles, but not sure we want that?
>
> Marek
>
>
>
> On 16/03/18 14:27, Pedro Igor Silva wrote:
>
> We already had discussions a long time ago about it. I do think that
> scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
> are too role-based ...
>
>
>
> Thinking it simple, as an admin user I may want to:
>
>
>
> * Create a scope "device.localization" with consent required for a client
>
>
>
> As a client:
>
>
>
> * Ask for "device.localization" scope when obtaining tokens from AS
>
>
>
> As a resource server:
>
>
>
> * Check if scope "device.localization" is granted by introspecting the
> token. For instance, checking a scope claim within a token.
>
>
>
> See, no role mapping, no scope -> role mapping, etc. User just consented
> to grant "device.localization" scope.
>
>
>
> On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
> On 16/03/18 13:24, Pedro Igor Silva wrote:
>
> That is what I was thinking. In authz services, scopes are not related
> with roles or protocol mappers. They are just a string representing
> something you can perform/access in a protected resource. Use client scopes
> to represent such concept and remove "authz scopes" tab is a bit overkill,
> I think.
>
>
>
> Currently, if I have a Localization API and a scope that grants access
> based on a "device.localization" scope, I would need to create a
> role/mapper and associate it with a client scope, right ?
>
> You mean that you have support for "device.localization" value of OAuth
> scope parameter? Yes, you would need to create clientScope and associate
> role "device.localization" with it. With client scopes support, the scope
> parameter doesn't reference single role, but single client scope.
>
> Marek
>
>
>
>
>
> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
> Scope parameter would reference client scopes. For example scope
> parameter "openid email profile offline_access" will reference client
> scopes "email", "profile" and "offline_access" (openid
is jsut generic
> OpenID Connect marker). And each client scope is set of protocolMappers
> and/or Role scope mappings.
>
> Marek
>
>
>
> On 15/03/18 12:39, Pedro Igor Silva wrote:
>
> How a scope looks like now after your changes ? Are they just strings
> referencing a set of one or more roles ? Or they are still roles ?
>
>
>
> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com>
> wrote:
>
> That's good question. As you know, we also have "Scope" tab (used to
> specify scope role mappings of client) and "Authorization scope", which
> is used when Authorization is enabled :)
>
> Marek
>
>
> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> > Hi,
> >
> > I saw there are activities to replace client templates with client
> scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
> client wants to do with the granted access (e.g. this could be used to
> determine the purpose of processing some data for GDPR compliance). Since
> Keycloak will also support UMA 2.0, I am a little concerned this might lead
> to some confusion. As you know, there are only two hard problems in
> computer science: cache invalidation, naming things, and off-by-one errors.
> ☺ WDYT?
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Dr.-Ing. Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY
>
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
> | www.bosch-si.com<http://www.bosch-si.com>
> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30
> 726112-100 | Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bo
> sch-si.com>
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr. Stefan Ferber, Michael Hahn
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
4:56 a.m.
+1
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: Montag, 19. März 2018 18:31
To: Pedro Igor Silva <psilva(a)redhat.com>; Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Client Scope naming
I see. I think you guys have very good points. I've created JIRA
https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return
"scope" in the access token.
With my PR, the "scope" is already returned in the TokenResponse as defined in
the OAuth2 [1] . But Introspection endpoint doesn't return "scope" because
access token doesn't yet have scope in my PR.
I've just added scope information to the refresh token, but I didn't add scope
claim directly. I've added "client-scopes" claim to the refresh token with
the list of UUIDs referencing used client scopes. I did this just because:
a) refreshToken is opaque to the application and just Keycloak needs to be able to read it
and decode used client scopes from it.
b) referencing by UUID is in theory bit safer instead of referencing by scope names. I was
just thinking about corner case when admin deletes scope "foo" and then
re-create scope "foo" again, it would be something different then what user
granted, even if it's same name. Hence I used reference by UUID. But this is probably
just corner case, which won't happen in practice.
When thinking more about it, it seems that none of the points (a) and (b) justifies this
unecessary complication with using "client-scopes" rather then just
"scope". It will be just easier if both access token and refreshToken contains
"scope" claim in the OAuth2 format. WDYT?
[1] https://tools.ietf.org/html/rfc6749#section-5.1
Marek
On 19/03/18 13:59, Pedro Igor Silva wrote:
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
If you support scopes you definitely need some claims in the token that represent the
granted scopes. Otherwise as a resource server you could only do token introspection to
retrieve the scopes and having to do this always defeats the purpose of self-contained
tokens. The fact that Keycloak supports defining custom mappings of scopes to roles (and
now arbitrary claims with token mappers) is just fine, I think.
Btw. access tokens and scopes is not always user consent, see client credentials grant…
Yeah, that is why I said usually. My initial idea was discuss cases where scopes are *not*
limited to the protected resources under the control of the client.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
726112-100<tel:+49%2030%20726112100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
From: Pedro Igor Silva [mailto:psilva@redhat.com<mailto:psilva@redhat.com>]
Sent: Montag, 19. März 2018 13:19
To: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>
Cc: Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>;
keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Subject: Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know they are opaque - so you
can push whatever you want into it, use it as a reference, etc. But if you look
https://tools.ietf.org/html/rfc7662 you'll see that token introspection response
includes a "scope" claim.
The main point I'm trying to make here is that access tokens usually represent user
consent. Consent is not the same thing as a role granted to an user. So I may want to
build my REST API without any role mapping but based on user consent to specific scopes.
Where these scopes grant access to different parts of my API.
But I think that should also be possible with your changes. We would just need to have a
mapper that adds to an access token the scopes granted by the user to a client. Or maybe
make this information also available via introspection endpoint (which I think we are
missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Yes, and this (almost) all should be possible now with new client scopes stuff I did. It
won't be a problem to have "device.localization" client scope, which
doesn't have any roles or protocolMappers. And require this client scope to be present
on consent screen.
Only thing, which is not directly available OOTB from what you mentioned, is the: Check if
scope "device.localization" is granted by introspecting the token. For instance,
checking a scope claim within a token.
For now, I've just added client scopes to refresh token, but that one is opaque to the
adapter. I did not add anything to access token or ID token. The "scope" claim
is not defined on OIDC or OAuth2, so we don't have it in our tokens. Do you know if
it's defined in some other specification? We can do our extension and add some stuff
into access token similarly like we did for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that scopes are a first
class citizen when doing OIDC and OAuth2, not RBAC. We are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the token.
For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented to grant
"device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not related with roles or
protocol mappers. They are just a string representing something you can perform/access in
a protected resource. Use client scopes to represent such concept and remove "authz
scopes" tab is a bit overkill, I think.
Currently, if I have a Localization API and a scope that grants access based on a
"device.localization" scope, I would need to create a role/mapper and associate
it with a client scope, right ?
You mean that you have support for "device.localization" value of OAuth scope
parameter? Yes, you would need to create clientScope and associate role
"device.localization" with it. With client scopes support, the scope parameter
doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Scope parameter would reference client scopes. For example scope parameter "openid
email profile offline_access" will reference client scopes "email",
"profile" and "offline_access" (openid is jsut generic OpenID Connect
marker). And each client scope is set of protocolMappers and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings referencing a set of
one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
Hi,
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses
the term “client scope” to determine what the OAuth client wants to do with the granted
access (e.g. this could be used to determine the purpose of processing some data for GDPR
compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might
lead to some confusion. As you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%...
| www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:07 a.m.
Great discussion, I think many folks are looking forward to enhanced scope
support in Keycloak.
I also think that having scopes in the RefreshToken as well as the
AccessToken
structure is useful.
Some additional remarks:
* backwards compatibility
Changing the representation of the token structures might cause problems
for clients using an older version of a Keycloak adapter when trying to
unmarshall
the JSON due to the unknown "client-scopes" field.
This incompatibility should be mentioned in the migration guides for 4.x.
* Scopes in general
As far as the current discussion goes the current understanding of custom
scopes (apart from role based scopes) seems to be "scoped" to client-level
since there is no mentioning of something like global scopes on realm level.
I wonder whether it would make sense to have support for broader global
scopes
on realm level, this could help to implement cross-cutting scopes across
all clients.
* Scope translation / rendering on consent page
When requesting consent for a scope from the user in a consent screen it
would be handy to have a way to use parameters for the translation of a
particular scope.
This would allow to render consent requests like
"Access to email: foo(a)bar.com" , "Access to User attribute: Date of
Birth"
Cheers,
Thomas
2018-03-20 10:56 GMT+01:00 Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com>:
+1
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: Montag, 19. März 2018 18:31
To: Pedro Igor Silva <psilva(a)redhat.com>; Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Client Scope naming
I see. I think you guys have very good points. I've created JIRA
https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return
"scope" in the access token.
With my PR, the "scope" is already returned in the TokenResponse as
defined in the OAuth2 [1] . But Introspection endpoint doesn't return
"scope" because access token doesn't yet have scope in my PR.
I've just added scope information to the refresh token, but I didn't add
scope claim directly. I've added "client-scopes" claim to the refresh
token
with the list of UUIDs referencing used client scopes. I did this just
because:
a) refreshToken is opaque to the application and just Keycloak needs to be
able to read it and decode used client scopes from it.
b) referencing by UUID is in theory bit safer instead of referencing by
scope names. I was just thinking about corner case when admin deletes scope
"foo" and then re-create scope "foo" again, it would be something
different
then what user granted, even if it's same name. Hence I used reference by
UUID. But this is probably just corner case, which won't happen in practice.
When thinking more about it, it seems that none of the points (a) and (b)
justifies this unecessary complication with using "client-scopes" rather
then just "scope". It will be just easier if both access token and
refreshToken contains "scope" claim in the OAuth2 format. WDYT?
[1] https://tools.ietf.org/html/rfc6749#section-5.1
Marek
On 19/03/18 13:59, Pedro Igor Silva wrote:
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
If you support scopes you definitely need some claims in the token that
represent the granted scopes. Otherwise as a resource server you could only
do token introspection to retrieve the scopes and having to do this always
defeats the purpose of self-contained tokens. The fact that Keycloak
supports defining custom mappings of scopes to roles (and now arbitrary
claims with token mappers) is just fine, I think.
Btw. access tokens and scopes is not always user consent, see client
credentials grant…
Yeah, that is why I said usually. My initial idea was discuss cases where
scopes are *not* limited to the protected resources under the control of
the client.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | <
https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+
Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g> GERMANY | www.bosch-si.com
<http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
726112-100<tel:+49%2030%20726112100> | Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn
From: Pedro Igor Silva [mailto:psilva@redhat.com<mailto:psilva@redhat.com
>]
Sent: Montag, 19. März 2018 13:19
To: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>
Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>; keycloak-dev <
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Subject: Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know they are
opaque - so you can push whatever you want into it, use it as a reference,
etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that
token introspection response includes a "scope" claim.
The main point I'm trying to make here is that access tokens usually
represent user consent. Consent is not the same thing as a role granted to
an user. So I may want to build my REST API without any role mapping but
based on user consent to specific scopes. Where these scopes grant access
to different parts of my API.
But I think that should also be possible with your changes. We would just
need to have a mapper that adds to an access token the scopes granted by
the user to a client. Or maybe make this information also available via
introspection endpoint (which I think we are missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Yes, and this (almost) all should be possible now with new client scopes
stuff I did. It won't be a problem to have "device.localization" client
scope, which doesn't have any roles or protocolMappers. And require this
client scope to be present on consent screen.
Only thing, which is not directly available OOTB from what you mentioned,
is the: Check if scope "device.localization" is granted by introspecting
the token. For instance, checking a scope claim within a token.
For now, I've just added client scopes to refresh token, but that one is
opaque to the adapter. I did not add anything to access token or ID token.
The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in
our tokens. Do you know if it's defined in some other specification? We can
do our extension and add some stuff into access token similarly like we did
for roles, but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think that
scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We
are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting the
token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just consented
to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not related
with roles or protocol mappers. They are just a string representing
something you can perform/access in a protected resource. Use client scopes
to represent such concept and remove "authz scopes" tab is a bit overkill,
I think.
Currently, if I have a Localization API and a scope that grants access
based on a "device.localization" scope, I would need to create a
role/mapper and associate it with a client scope, right ?
You mean that you have support for "device.localization" value of OAuth
scope parameter? Yes, you would need to create clientScope and associate
role "device.localization" with it. With client scopes support, the scope
parameter doesn't reference single role, but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Scope parameter would reference client scopes. For example scope parameter
"openid email profile offline_access" will reference client scopes
"email",
"profile" and "offline_access" (openid is jsut generic OpenID
Connect
marker). And each client scope is set of protocolMappers and/or Role scope
mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just strings
referencing a set of one or more roles ? Or they are still roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope", which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to replace client templates with client
scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth
client wants to do with the granted access (e.g. this could be used to
determine the purpose of processing some data for GDPR compliance). Since
Keycloak will also support UMA 2.0, I am a little concerned this might lead
to some confusion. As you know, there are only two hard problems in
computer science: cache invalidation, naming things, and off-by-one errors.
☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+
12109+Berlin+%7C+GERMANY&entry=gmail&source=g> | www.bosch-si.com<
http://www.bosch-si.com><http://www.bosch-si.com>
> Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> | Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian
.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr. Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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
7:01 a.m.
Dne 4.4.2018 v 11:07 Thomas Darimont napsal(a):
Great discussion, I think many folks are looking forward to enhanced
scope support in Keycloak.
I also think that having scopes in the RefreshToken as well as the
AccessToken
structure is useful.
Some additional remarks:
* backwards compatibility
Changing the representation of the token structures might cause problems
for clients using an older version of a Keycloak adapter when trying
to unmarshall
the JSON due to the unknown "client-scopes" field.
This incompatibility should be mentioned in the migration guides for 4.x.
Good
point. I think it won't be an issue for our java adapters. The
JsonWebToken class contains field "otherClaims", which contains all the
claims without getter/setter. So if our older adapter reads new
accessToken, the "scope" will be just put as attribute to
"otherClaims"
. But it might be an issue for our Node.js adapter (maybe?) and for 3rd
party adapters, which parse our accessToken and rely on it's format.
Agree will be good to put to the migration guide.
* Scopes in general
As far as the current discussion goes the current understanding of custom
scopes (apart from role based scopes) seems to be "scoped" to client-level
since there is no mentioning of something like global scopes on realm
level.
I wonder whether it would make sense to have support for broader
global scopes
on realm level, this could help to implement cross-cutting scopes
across all clients.
The clientScopes will be defined at realm level similarly like
currently
clientTemplates. So the definition of clientScope itself (EG. which
protocolMappers and role scope mappings it contains) is at realm level.
At client level, you can just assign clientScope to client. There will
also be "Default client scopes" - those are automatically added to new
clients, but can be then manually removed from clients.
* Scope translation / rendering on consent page
When requesting consent for a scope from the user in a consent screen it
would be handy to have a way to use parameters for the translation of
a particular scope.
This would allow to render consent requests like
"Access to email: foo(a)bar.com <mailto:foo@bar.com>" , "Access to
User
attribute: Date of Birth"
In the clientScope PR, it supports localization, but
not parameters.
Feel free to create JIRA for parameters.
Marek
Cheers,
Thomas
2018-03-20 10:56 GMT+01:00 Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>:
+1
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
| GERMANY | www.bosch-si.com
<http://www.bosch-si.com><http://www.bosch-si.com
<http://www.bosch-si.com>>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
From: Marek Posolda [mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>]
Sent: Montag, 19. März 2018 18:31
To: Pedro Igor Silva <psilva(a)redhat.com
<mailto:psilva@redhat.com>>; Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
Subject: Re: [keycloak-dev] Client Scope naming
I see. I think you guys have very good points. I've created JIRA
https://issues.jboss.org/browse/KEYCLOAK-6883
<https://issues.jboss.org/browse/KEYCLOAK-6883> to make sure that
we return "scope" in the access token.
With my PR, the "scope" is already returned in the TokenResponse
as defined in the OAuth2 [1] . But Introspection endpoint doesn't
return "scope" because access token doesn't yet have scope in my PR.
I've just added scope information to the refresh token, but I
didn't add scope claim directly. I've added "client-scopes" claim
to the refresh token with the list of UUIDs referencing used
client scopes. I did this just because:
a) refreshToken is opaque to the application and just Keycloak
needs to be able to read it and decode used client scopes from it.
b) referencing by UUID is in theory bit safer instead of
referencing by scope names. I was just thinking about corner case
when admin deletes scope "foo" and then re-create scope "foo"
again, it would be something different then what user granted,
even if it's same name. Hence I used reference by UUID. But this
is probably just corner case, which won't happen in practice.
When thinking more about it, it seems that none of the points (a)
and (b) justifies this unecessary complication with using
"client-scopes" rather then just "scope". It will be just easier
if both access token and refreshToken contains "scope" claim in
the OAuth2 format. WDYT?
[1] https://tools.ietf.org/html/rfc6749#section-5.1
<https://tools.ietf.org/html/rfc6749#section-5.1>
Marek
On 19/03/18 13:59, Pedro Igor Silva wrote:
On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>> wrote:
If you support scopes you definitely need some claims in the token
that represent the granted scopes. Otherwise as a resource server
you could only do token introspection to retrieve the scopes and
having to do this always defeats the purpose of self-contained
tokens. The fact that Keycloak supports defining custom mappings
of scopes to roles (and now arbitrary claims with token mappers)
is just fine, I think.
Btw. access tokens and scopes is not always user consent, see
client credentials grant…
Yeah, that is why I said usually. My initial idea was discuss
cases where scopes are *not* limited to the protected resources
under the control of the client.
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin
|
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AG...
GERMANY | www.bosch-si.com
<http://www.bosch-si.com><http://www.bosch-si.com
<http://www.bosch-si.com>>
Tel. +49 30 726112-485<tel:+49%2030%20726112485> | Fax +49 30
726112-100<tel:+49%2030%20726112100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
From: Pedro Igor Silva [mailto:psilva@redhat.com
<mailto:psilva@redhat.com><mailto:psilva@redhat.com
<mailto:psilva@redhat.com>>]
Sent: Montag, 19. März 2018 13:19
To: Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>>
Cc: Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>>; keycloak-dev
<keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org><mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>>
Subject: Re: [keycloak-dev] Client Scope naming
OAuth2 does not define any format for access tokens - as you know
they are opaque - so you can push whatever you want into it, use
it as a reference, etc. But if you look
https://tools.ietf.org/html/rfc7662
<https://tools.ietf.org/html/rfc7662> you'll see that token
introspection response includes a "scope" claim.
The main point I'm trying to make here is that access tokens
usually represent user consent. Consent is not the same thing as a
role granted to an user. So I may want to build my REST API
without any role mapping but based on user consent to specific
scopes. Where these scopes grant access to different parts of my API.
But I think that should also be possible with your changes. We
would just need to have a mapper that adds to an access token the
scopes granted by the user to a client. Or maybe make this
information also available via introspection endpoint (which I
think we are missing).
On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda
<mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>> wrote:
Yes, and this (almost) all should be possible now with new client
scopes stuff I did. It won't be a problem to have
"device.localization" client scope, which doesn't have any roles
or protocolMappers. And require this client scope to be present on
consent screen.
Only thing, which is not directly available OOTB from what you
mentioned, is the: Check if scope "device.localization" is granted
by introspecting the token. For instance, checking a scope claim
within a token.
For now, I've just added client scopes to refresh token, but that
one is opaque to the adapter. I did not add anything to access
token or ID token. The "scope" claim is not defined on OIDC or
OAuth2, so we don't have it in our tokens. Do you know if it's
defined in some other specification? We can do our extension and
add some stuff into access token similarly like we did for roles,
but not sure we want that?
Marek
On 16/03/18 14:27, Pedro Igor Silva wrote:
We already had discussions a long time ago about it. I do think
that scopes are a first class citizen when doing OIDC and OAuth2,
not RBAC. We are too role-based ...
Thinking it simple, as an admin user I may want to:
* Create a scope "device.localization" with consent required for a
client
As a client:
* Ask for "device.localization" scope when obtaining tokens from AS
As a resource server:
* Check if scope "device.localization" is granted by introspecting
the token. For instance, checking a scope claim within a token.
See, no role mapping, no scope -> role mapping, etc. User just
consented to grant "device.localization" scope.
On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda
<mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>> wrote:
On 16/03/18 13:24, Pedro Igor Silva wrote:
That is what I was thinking. In authz services, scopes are not
related with roles or protocol mappers. They are just a string
representing something you can perform/access in a protected
resource. Use client scopes to represent such concept and remove
"authz scopes" tab is a bit overkill, I think.
Currently, if I have a Localization API and a scope that grants
access based on a "device.localization" scope, I would need to
create a role/mapper and associate it with a client scope, right ?
You mean that you have support for "device.localization" value of
OAuth scope parameter? Yes, you would need to create clientScope
and associate role "device.localization" with it. With client
scopes support, the scope parameter doesn't reference single role,
but single client scope.
Marek
On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda
<mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>> wrote:
Scope parameter would reference client scopes. For example scope
parameter "openid email profile offline_access" will reference
client scopes "email", "profile" and "offline_access"
(openid is
jsut generic OpenID Connect marker). And each client scope is set
of protocolMappers and/or Role scope mappings.
Marek
On 15/03/18 12:39, Pedro Igor Silva wrote:
How a scope looks like now after your changes ? Are they just
strings referencing a set of one or more roles ? Or they are still
roles ?
On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda
<mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>> wrote:
That's good question. As you know, we also have "Scope" tab (used to
specify scope role mappings of client) and "Authorization scope",
which
is used when Authorization is enabled :)
Marek
On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote:
> Hi,
>
> I saw there are activities to replace client templates with
client scopes. UMA 2.0 uses the term “client scope” to determine
what the OAuth client wants to do with the granted access (e.g.
this could be used to determine the purpose of processing some
data for GDPR compliance). Since Keycloak will also support UMA
2.0, I am a little concerned this might lead to some confusion. As
you know, there are only two hard problems in computer science:
cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
Berlin |
GERMANY<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%...
<https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&...
| www.bosch-si.com
<http://www.bosch-si.com><http://www.bosch-si.com
<http://www.bosch-si.com>><http://www.bosch-si.com
<http://www.bosch-si.com>>
> Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>>>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org><mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org><mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
2228
days inactive
2249
days old
18 comments
4 participants
participants (4)
-
Marek Posolda -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Thomas Darimont