7:47 p.m.
----- Original Message -----
From: "John Dennis" <jdennis(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Marek Posolda"
<mposolda(a)redhat.com>
Cc: keycloak-dev(a)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