[keycloak-user] Roles without "Full Scope Allowed"?

Thu Feb 22 09:59:17 EST 2018

Hi Michael

Looks, like this issue, is exactly about this case

realm_access && resource_access claims are indeed only for access tokens.
There is no much sense in adding them to id_token

On Thu, Feb 22, 2018 at 5:56 PM Michael Poettgen <
Michael.Poettgen at oeconnection.com> wrote:

> Vitaliy,
>
>
>
> Forget the remark on realm_access and resource_access. I found them on the
> access_token and refresh_token (but not on the id_token, which may be why I
> couldn’t find them easily on the .NET Core OpenIdConnect authentication
> provider).
>
>
>
> I found https://issues.jboss.org/browse/KEYCLOAK-5259 by Luiz Carlos
> Viana Melo, with a comment by Manfred Duchrow which I found interesting. I
> left a comment there and voted for the issue instead of raising another one.
>
>
>
> Regards,
>
> Michael
>
>
>
> *From:* Michael Poettgen
> *Sent:* Wednesday, February 21, 2018 7:45 PM
> *To:* 'Виталий Ищенко'; Marek Posolda
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* RE: [keycloak-user] Roles without "Full Scope Allowed"?
>
>
>
> This describes pretty well what I’m getting as well. The only thing I
> don’t see is the realm_access and resource_access claims. Are they only
> enabled when activating Authorization?
>
>
>
> Regards,
>
> Michael
>
>
>
> *From:* Виталий Ищенко [mailto:betalb at gmail.com <betalb at gmail.com>
>
> ]
>
> *Sent:* Wednesday, February 21, 2018 6:03 PM
> *To:* Marek Posolda
>
> *Cc:* Michael Poettgen; keycloak-user at lists.jboss.org
>
>
> *Subject:* Re: [keycloak-user] Roles without "Full Scope Allowed"?
>
>
>
> 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 at 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 at 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 at gmail.com]
> *Sent:* Tuesday, February 20, 2018 6:41 PM
> *To:* Michael Poettgen
> *Cc:* Marek Posolda; keycloak-user at 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/7hHDCG6A12hNzkyckuOAm>
>
> 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 at 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 at redhat.com]
> Sent: Tuesday, February 20, 2018 2:13 PM
> To: Michael Poettgen; keycloak-user at 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/gqRFCJ6142hWjZ4iOhU4y>
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> <https://protect-us.mimecast.com/s/t_AiCKrGg2syROAUopQ22>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> <https://protect-us.mimecast.com/s/t_AiCKrGg2syROAUopQ22>
>
>
>
>