[keycloak-dev] Client Scope naming
Marek Posolda
mposolda at redhat.com
Fri Mar 16 09:12:59 EDT 2018
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 | 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