Hi Marek
The behaviour for automatically adding client own roles to scope seems
fine, the issue is with client mappers (or lack of documentation, hence
misunderstanding), their logic is not clear when full scope is not enabled.
Also at the bottom, I've mentioned two other quirks that can be observed
even with full scope enabled.
Suppose we have following setup
== Clients ==
client-with-roles
Roles:
* role
* role-composite-child
test-client
Roles:
* role
* role-composite-child
Mappers:
#1
type: User Client Type
client id: client-with-roles
claim: rolesOtherClient
#2
type: User Client Type
client id: test-client
claim: rolesCurrentClient
#3
type: User Realm Role
claim: rolesRealm
== REALM Roles ==
* ROLE
* ROLE_COMPOSITE_CHILD
* ROLE_COMPOSITE (contains ROLE_COMPOSITE_CHILD,
client-with-roles/role-composite-child, test-client/role-composite-child)
== Users ==
name: "a"
mapped roles
* ROLE
* ROLE_COMPOSITE
* test-client/role
* client-with-roles/role
Now if I issue token using test-client and user "a" credentials (direct
grant),
token will have following claims (they have the same set of roles
as realm_access and resource_access claims)
"rolesRealm": [
"ROLE",
"ROLE_COMPOSITE",
"ROLE_COMPOSITE_CHILD"
],
"rolesOtherClient": [
"role-composite-child",
"role"
],
"rolesCurrentClient": [
"role-composite-child",
"role"
]
But if I disable full scope and will add all user "a" roles to scope,
token will look like this (realm_access and resource_access haven't changed)
"rolesRealm": [
"ROLE",
"ROLE_COMPOSITE"
],
"rolesOtherClient": [
"role"
]
rolesCurrentClient claim is absent
Also Found few other strange behaviours with mappers
* realm-management roles are not mapped at all
* scoped roles are included into claims, produced by mappers,
even if scope parameter was not provided during token request
(This one may be useful get potential list of roles)
On Wed, Feb 21, 2018 at 10:35 AM Marek Posolda <mposolda(a)redhat.com> wrote:
Please create a JIRA if you think that it's a bug. Please add the
detailed
steps to reproduce. TBH from this email, I don't know what exactly is
broken, or if it's just misconfiguration.
BTV. Client has always automatically scope to his own roles. And it's not
possible to remove them from the scope. It's just possible to add/remove
scopes for realm roles or client roles of different clients. So the
behaviour described by Michael is expected.
Marek
On 20/02/18 20:51, Виталий Ищенко wrote:
I was able to reproduce this issue
It only happens for a claim, produced by the mapper.
But I can see correct list of roles in a different claim:
resource_access[clientId].roles.
It seems like a bug, you can raise it with the team.
As a workaround, you can use existing claim
On Tue, Feb 20, 2018 at 9:39 PM Michael Poettgen <
Michael.Poettgen(a)oeconnection.com> wrote:
> Betalb,
>
>
>
> That’s what I thought as well, but if I turn off „Full Scope Allowed“ and
> look at the „Client Roles“ of my client then all client roles appear under
> “Effective Roles”. I cannot assign or un-assign any of these roles. So my
> assumption was that, since these are all roles of my client anyways, that
> they would always be available (at least for my client). Also the user does
> have the proper roles (I get them with “Full Scope Allowed” enabled), but
> nevertheless I don’t get any.
>
>
>
> Thanks,
>
> Michael
>
>
>
> *From:* Виталий Ищенко [mailto:betalb@gmail.com]
> *Sent:* Tuesday, February 20, 2018 6:41 PM
> *To:* Michael Poettgen
> *Cc:* Marek Posolda; keycloak-user(a)lists.jboss.org
>
>
> *Subject:* Re: [keycloak-user] Roles without "Full Scope Allowed"?
>
>
>
> This is mentioned in docs:
>
http://www.keycloak.org/docs/latest/server_admin/index.html#_client_scope
> <
https://protect-us.mimecast.com/s/lPgJCOYGm2ULDEGtr7uCs>
>
> If full scope is disabled: access token, issued to specific client will
> have intersection of user own roles with client scope, defined in scope
> section of client configuration
>
> вт, 20 февр. 2018 г. в 16:34, Michael Poettgen <
> Michael.Poettgen(a)oeconnection.com>:
>
> You said, that I need to "add scopes for the *realm roles* and client
> roles of *other clients*", but I don't even get the roles for this client
> anymore, no matter whether "Scope Param Required" is set for the role or
> not and no matter whether I add the role names to the "scope" or not.
>
> Michael
>
> From: Marek Posolda [mailto:mposolda@redhat.com]
> Sent: Tuesday, February 20, 2018 2:13 PM
> To: Michael Poettgen; keycloak-user(a)lists.jboss.org
> Subject: Re: [keycloak-user] Roles without "Full Scope Allowed"?
>
> Once you changed "Full Scope Allowed" to off, you need to add scopes for
> the realm roles and client roles of other clients. This can be done in
> the "Scope" tab, pretty much same place where you turned "Full Scope
> Allowed" to off. I think we have also some docs around this somewhere
> (not 100% sure).
>
> Marek
>
> On 20/02/18 13:07, Michael Poettgen wrote:
> > All,
> >
> > I've got Keycloak 3.4.3 configured to return client roles in a
"role"
> Claim to an OpenID Connect client. (The client has got a list of roles,
> these are assigned to the user and I've got a User Client Role Token mapper
> that maps the roles of that client into the "role" claim.) Everything
works
> until I turn "Full Scope Allowed" off. Then all roles disappear and trying
> to request the roles via the "scope" (with or without client ID prefix)
> doesn't seem to work.
> >
> > Am I doing something stupid or is there something that does not work as
> (I) expected?
> >
> > Thanks for your help!
> >
> > Michael
> >
> >
> > This message may contain confidential information. If you are not the
> intended recipient, do not disseminate, distribute, or copy this e-mail or
> its attachments. Please notify the sender of the error immediately by
> e-mail or at the telephone number listed below, and delete this e-mail and
> any attachments from your system. Receipt by anyone other than the intended
> recipient(s) is not a waiver of any trade secrets, proprietary interests,
> or other applicable rights. E-mail transmission is not necessarily secure
> or error-free, as information could be intercepted, corrupted, lost,
> destroyed, delayed, incomplete, or may contain viruses. The sender
> disclaims all liability for any errors or omissions arising as a result of
> the e-mail transmission.
> >
> > OEConnection LLC, (888) 776-5792,
www.oeconnection.com
> <
https://protect-us.mimecast.com/s/CIajCPNGn9h1BJlf6VFQq>
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/keycloak-user
> <
https://protect-us.mimecast.com/s/inGTCQWXo2u1nJxfA0ANj>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
> <
https://protect-us.mimecast.com/s/inGTCQWXo2u1nJxfA0ANj>
>
>