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