[keycloak-dev] Client Scope naming
Marek Posolda
mposolda at redhat.com
Wed Apr 4 08:01:46 EDT 2018
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 at bar.com <mailto:foo at 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 at bosch-si.com
> <mailto:Sebastian.Schuster at 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 at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at 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 at redhat.com
> <mailto:mposolda at redhat.com>]
> Sent: Montag, 19. März 2018 18:31
> To: Pedro Igor Silva <psilva at redhat.com
> <mailto:psilva at redhat.com>>; Schuster Sebastian (INST/ESY1)
> <Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at 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
> <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><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 at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at 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 at redhat.com
> <mailto:psilva at redhat.com><mailto:psilva at redhat.com
> <mailto:psilva at redhat.com>>]
> Sent: Montag, 19. März 2018 13:19
> To: Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
> <mailto:mposolda at redhat.com>>>
> Cc: Schuster Sebastian (INST/ESY1)
> <Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>>>; keycloak-dev
> <keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at redhat.com
> <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
> <mailto:mposolda at 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 at redhat.com
> <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
> <mailto:mposolda at 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 at redhat.com
> <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
> <mailto:mposolda at 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 at redhat.com
> <mailto:mposolda at redhat.com><mailto:mposolda at redhat.com
> <mailto:mposolda at 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
> <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
> <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 at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com>><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com
> <mailto:Sebastian.Schuster at 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 at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
More information about the keycloak-dev
mailing list