[keycloak-dev] Client Scope naming
Marek Posolda
mposolda at redhat.com
Mon Mar 19 04:22:03 EDT 2018
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>> 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>> 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>> 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
>>> <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>>
>>> >
>>> > 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>
>>> > 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