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.