2:37 p.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
9 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:
1:11 p.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
1:21 p.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:
8: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:
1:24 p.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:
2:12 p.m.
On 16/03/18 13:24, Pedro Igor Silva wrote:
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
2:27 p.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:
9: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:
1:18 p.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:
1:33 p.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:
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6: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:
10: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:
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11: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>:
2:01 p.m.
Dne 4.4.2018 v 11:07 Thomas Darimont napsal(a):
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.
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.
In the clientScope PR, it supports localization, but
not parameters.
Feel free to create JIRA for parameters.
Marek
2537
days inactive
2558
days old
18 comments
4 participants
participants (4)
-
Marek Posolda -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Thomas Darimont