Okay, I'm trying to wrap my head around this - please correct me if I'm
wrong:
- All of our users are required to get all of the roles that potentially
are used by clients. Can we automate this (we've got many users, which
varying life cycles)?
- In the (keycloak-sided) configuration of clients (that authenticate
users), we limit what roles can be included in the access token that's
generated for that client
- In the code of the clients (that act as resource servers), we verify
that the required role is in place (assuming that authentication itself
succeeded in the first place).
On 1 November 2016 at 10:36, Sebastien Blanc <sblanc(a)redhat.com> wrote:
On Tue, Nov 1, 2016 at 10:16 AM, Guus der Kinderen <
guus.der.kinderen(a)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(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>