[keycloak-dev] Client Scope naming
Pedro Igor Silva
psilva at redhat.com
Thu Mar 15 08:21:42 EDT 2018
It is a pertinent concern. That scope parameters is something clients can
use to ask for additional scopes after receiving a ticket (with can already
some scopes defined by the RS). Right now the resource server is
responsible for defining these scopes.
The thing is that scopes in authz services can be anything and they don't
really represent a access context. For instance, scopes can be actions you
can perform on a resource, information about a resource, etc.
I just checked UMA 2.0 grant type implementation and we are already
considering any addition scope defined by the client using the "scope"
parameter.
On Thu, Mar 15, 2018 at 9:11 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:
> I just checked the UMA 2.0 spec again and I found that the term “client
> scope” is not used directly. It is just called scope but associated to the
> client and not the resource server,
>
> See section 3.3.1 Client Request to Authorization Server for RPT in :
> https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
>
>
>
> scope
>
> OPTIONAL. A string of space-separated values representing requested
> scopes. For the authorization server to consider any requested scope in its
> assessment, the client MUST have been pre-registered for the same scope
> with the authorization server. The client should consult the resource
> server's API documentation for details about which scopes it can expect the
> resource server's initial returned permission ticket to represent as part
> of the authorization assessment (see Section 3.3.4).
>
>
>
> The resource server has its own set of scopes that is also used assess
> authorizations, see section 3.3.4 Authorization Assessment and Results
> Determination.
>
>
>
> I just fear the term „scope“ is a bit overused…
>
>
>
> 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:* Mittwoch, 14. März 2018 21:01
> *To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] Client Scope naming
>
>
>
> I need to take a closer look on what Marek did around client scopes. So
> far, scopes were basically associated with roles and protocol mappers and
> that is not really what we need in UMA 2.0.
>
>
>
> If scopes now is more abstract and we can remove "authorization scopes" in
> authz services, I need to take a look ...
>
>
>
> In fact, I need to review scope parameter in UMA grant type in order to
> allow clients to push additional scopes other those already added in a
> ticket.
>
>
>
> On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster at bosch-si.com> 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>
> 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
>
>
>
More information about the keycloak-dev
mailing list