[keycloak-dev] Client Scope naming

[Pedro Igor Silva]

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
>>>
>>
>>
>>
>
>