[keycloak-dev] Scope parameter support

[Pedro Igor Silva]

----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, June 30, 2016 6:29:01 PM
> Subject: Re: [keycloak-dev] Scope parameter support
> 
> On 06/30/2016 03:42 PM, Pedro Igor Silva wrote:
> > IMO, roles and scopes are separated concepts. Where scopes may also
> > implicate access to the roles granted to an user. Scopes have a
> > pretty broad meaning.
> >
> > With that in mind, don't you think that we could just have a scope
> > "roles" ? Which could be used to ask for the roles associated with
> > the user that the client is acting on behalf of ?
> >
> > I think that the Protocol Mappers (for OIDC) provide pretty much
> > everything you need. The missing part would be to make it capable of
> > grouping other mappers. Actually, the concept behind a protocol
> > mapper is pretty much related with a scope.
> 
> I think it would be valuable for the Keycloak team to define and publish
> what it thinks the terms "scope" and "role" mean and how those values
> propagate through Keycloak (e.g. where do they come from, if they are
> synthesized from other values then how). As well as their intended use.
> 
> People may be coming to Keycloak with a different set of assumptions on
> what those terms mean.
> 
> At the same time it would be worthwhile to include a discussion of
> groups and how they relate to roles (and scope?). That is because many
> applications define and manage roles themselves and assign roles based
> on group attributes returned in an assertion/claim attribute. Typically
> we have not expected an IdP to assign roles to a user. In an application
> which supports multiple IdP's (other than Keycloak, e.g. federation) you
> simply cannot assume the IdP can map a user into a role. Mapping a user
> into a role is usually application specific logic synthesized from
> attributes bound to the user principal.

I guess we share the same ideas about roles and groups. 

Scopes are heavily mentioned by both OAuth2 and OIDC specs and they usually limit the authorization granted to the client by the resource owner.

Scopes have a pretty broad meaning as they can represent a single attribute, a group of attributes, an action on a particular resource managed by a resource server, etc. Even roles can have a scope, so you are basically saying that a client is allowed to access that info on behalf of the user or resource owner.

In Keycloak, you can grant roles directly to an user or to the group he belongs to. But that doesn't mean that you can't do your own role mapping based on the claims returned within an access token. I share the same opinion about federation and multiple IdP scenarios, but there are a lot of people that also expect the IdP granting roles to an user. Specially when there is an 1:N mapping between IdPs and SPs.

Beside that, you would usually prefer assign roles to a group (group of users) than to each user individually. It makes management easier ...

> 
> --
> John
>