[keycloak-user] Using a role to allow access to a resource

Sebastien Blanc sblanc at redhat.com
Tue Nov 1 05:36:07 EDT 2016


On Tue, Nov 1, 2016 at 10:16 AM, Guus der Kinderen <
guus.der.kinderen at gmail.com> wrote:

> ah, no - users don't have any roles assigned.
>
> Should users each have individually assigned all roles that can be used?
>
yes

> Can we prevent one client from obtaining an access token with a role
> that's not intended to be used by that role?
>
Wel not directly with auth, you will still be authnticated, you can just
limit the roles that will be contained in the token (by doing it the way
you did it initially with client scope). Maybe with authorization you can
achieve this.

>
> On 1 November 2016 at 10:13, Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> Your token will contain the roles of the user, not the roles of the
>> client. Does your user have the roles assigned ?
>>
>> On Tue, Nov 1, 2016 at 9:41 AM, Guus der Kinderen <
>> guus.der.kinderen at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> While trying to authenticate a user to obtain a resource, I'm running
>>> into
>>> an issue. It's likely caused by my misunderstanding of how things are
>>> supposed to work, rather than some kind of bug. I'd love to be corrected.
>>>
>>> Using Keycloak 1.9.2, I've created a realm with two clients. One client
>>> is
>>> using the Javascript adapter[1] to create a very simply UI, that lets the
>>> user authenticate. The resulting access token is used to make a request
>>> to
>>> a REST-like service, which employs the Java Servlet Filter Adapter[2].
>>>
>>> We're planning to have multiple resource services like this, each
>>> exposing
>>> data for which different levels of authorization might be required.
>>>
>>> I'd like our REST-like service to provide data only when the user that
>>> requests the data has an access token that is issued to a front-end that
>>> is
>>> allowed to access this data. To achieve this, I tried employing the use
>>> of
>>> a role. I think this is where I'm messing up somehow.
>>>
>>> What I did:
>>>
>>> In the realm, I've a added a "realm role" ( "scope param required" /
>>> "composite roles" both disabled)
>>>
>>> In the client configuration that's used by the Javascript UI (which
>>> generates the access token), I've made these changes to the "scope" tab:
>>>
>>>    - Disabled "Full Scope Allowed"
>>>    - Moved the role that I added earlier from "available roles" to
>>>
>>>    "assigned roles"
>>>
>>> Finally, I've modified the implementation of the REST-like service to
>>> check
>>> for the new role, by doing something like this simplified code in a
>>> servlet
>>> (that's covered by the OIDC Filter):
>>>
>>> KeycloakSecurityContext securityContext = (KeycloakSecurityContext)
>>> request.getAttribute( KeycloakSecurityContext.class.getName() );
>>> if ( !securityContext.getToken().getRealmAccess().isUserInRole(
>>> "the-role-that-I-added" ) )
>>> {
>>>     response.setStatus( HttpServletResponse.SC_FORBIDDEN );
>>>     return;
>>> }
>>>
>>> This throws a NullPointerException, as getRealmAccess() returns null.
>>>
>>> While debugging the code, it's appears that the access token itself is
>>> received and valid - it's the scope / role check that does not appear to
>>> come through.
>>>
>>> I finally used the service at https://jwt.io/ to inspect the content of
>>> the
>>> access token that's being generated. I expected the
>>> 'the-role-that-I-added"
>>> value to be in there somewhere, but that's not the case.
>>>
>>> That's where I thought it'd be a good idea to get some advice, and here
>>> we
>>> are. I'd love some feedback.
>>>
>>> Regards,
>>>
>>>   Guus
>>>
>>> [1]:
>>> https://keycloak.gitbooks.io/securing-client-applications-gu
>>> ide/content/topics/oidc/javascript-adapter.html
>>> [2]:
>>> https://keycloak.gitbooks.io/securing-client-applications-gu
>>> ide/content/topics/oidc/java/servlet-filter-adapter.html
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>


More information about the keycloak-user mailing list