[keycloak-dev] Client Scope naming

[Pedro Igor Silva]

On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) <
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>
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100
> <+49%2030%20726112100> | 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]
> *Sent:* Montag, 19. März 2018 13:19
> *To:* Marek Posolda <mposolda at redhat.com>
> *Cc:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> keycloak-dev <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 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>
> 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>
> 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>
> 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>
> 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>
> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> 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
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>