[keycloak-user] FW: Access control and client setup

[Pedro Igor Silva]

On Tue, Aug 7, 2018 at 3:52 AM, Wyns Dean <dean.wyns at aptus.be> wrote:

> Hi Pedro
>
>
>
> Thanks, that has clarified a lot already.
>
>
>
> There are still some things that we’re a bit uncertain about.
>
>
>
>    1. Can you restrict scopes to certain roles? Like for example the
>    OAuth client requests scope “item:read item:delete”, but the authenticated
>    user only has the role to view items. So I would expect the resulting scope
>    in the access token to be “item:view”, but Keycloak always seems to put the
>    requested scope in the access token (+ the default client scopes). I
>    understand that Keycloak uses scope to limit the role mappings that get
>    assigned to the access token. I’m just wondering if we could use the scope
>    as “permissions granted” if we could restrict it (just like Auth0, where
>    they limit the scope according to the user’s permissions and the server
>    checks the scope).
>
> AFAIK, with client scopes you are allowed to restrict roles based on
scopes not the inverse. But I think we can also support this. Could you
create a RFE ?


>
>    1. Is it possible to remove/hide the “resource_access” and/or
>    “realm_access” claims from the access token?Is it possible to add a
>    custom claim “permissions” to the token which is the list of the user’s
>    roles (with a script protocol mapper maybe?)
>
> You could create a script mapper to your client with a code similar to the
following:

    token.setRealmAccess(null);

The same goes to "resource_access" (client scopes):

    token.setResourceAccess(null);

One of the problems using a script mapper is performance. Depending on how
many calls you have to the token endpoint it may take more time to issue
tokens because of the processing of the JS code.

There is also the ProtocolMapper SPI. But it is a private SPI.

There is this JIRA [1] tracking this too.

[1] https://issues.jboss.org/browse/KEYCLOAK-3455 and
https://issues.jboss.org/browse/KEYCLOAK-6884



>
>    1. What is the recommended way to model simple authorization? Still
>    not really sure which way to go.
>    The API is just a simple CRUD for some models (items, item types, …),
>    and each model has a permission/role for each action (create, read, update,
>    delete). Would you go with authorization based on OAuth scopes (client
>    scopes) or with the authorization model that Keycloak provides? We don’t
>    really need the fine-grained permissions yet, so I’d say we’d go with the
>    client scopes.
>
> I think your use case fits better with the authorization services model.
It should be a very simple setup:

* Create a "Item" resource
* Create "view" and "delete" scopes and associate them to the resource
* Create two role policies for each role you want to restrict (supposing
each role grants access to a specific scope). Our model allows you to reuse
policies across different permissions, you migh want to reuse these two to
define permissions to other resources.
* Create a permission linking each scope with the the corresponding role
policy

You could even have a single JS policy (instead of two role policies) where
you programmaticaly check if the user is granted with a role that have
access to any of these scopes.

>From your application, you could enforce access based on permissions by:

* Ask the server for permissions when a request arrives to your application
* Force your clients to obtain first a token with permissions so our app
just need to check the token and the permissions that were granted

There are some advantages in this model:

* You have a better representation of the resources and scopes you are
protecting as they are being managed by Keycloak
* Although this is not what you need at the moment, you also have more
flexibility to use different access control mechanisms as well adapt
changes in your requirements faster
* Access control is based on the resources you are protecting (and their
actions) instead of individual roles or single scopes
* if your application is obtaining decisions from server for each request,
you may grant/deny permissions without having to obtain a new token

Hope it helps.


>
>
> Thanks a lot!
>
>
>
> Kind regards
>
> Dean
>
>
>
> *Van:* Pedro Igor Silva <psilva at redhat.com>
> *Verzonden:* Monday 30 July 2018 17:52
>
> *Aan:* Wyns Dean <dean.wyns at aptus.be>
> *CC:* keycloak-user at lists.jboss.org
> *Onderwerp:* Re: [keycloak-user] FW: Access control and client setup
>
>
>
> On Mon, Jul 30, 2018 at 10:43 AM, Wyns Dean <dean.wyns at aptus.be> wrote:
>
> Hi Pedro
>
>
>
> Thanks for your answer.
>
>
>
> So the idea is to create one client for the API, let’s call it “my-api”
> with authorization enabled and the resources/scopes/permissions like you
> described previously. And I’ll create another (public) client for the SPA,
> “my-app”.
>
>
>
> If users authenticate against my-app using the implicit flow, how can I
> link the scopes associated with the resources of my-api and have them
> follow the permissions that are defined on my-api? Do I have to add the
> scopes as optional “Client Scopes” so they are shared? The problem then is
> that they don’t show up under the Authorization tab of my-api, only the
> Authorization Scopes do. Or should authorization be enabled for my-app as
> well?
>
>
>
> Client Scopes and Authorization tabs are different features. The first
> provides an authorization model based on OAuth2 scopes, where scopes may
> map to one or more claims inside your token or even restrict the roles you
> send n the token. They are also related with user consent.
>
>
>
> The Authorization provides you the necessary means to setup resource-based
> permissions using different access control mechanisms. It also provides
> privacy based on user-managed access.
>
>
>
>
>
> I would like the backend to purely check on the scope associated with the
> access token, by looking at the scope claim. There doesn’t seem to ever be
> a permissions claim in my tests, I only get the “resource_access” claim but
> that only contains the roles, which I don’t need in the backend.
>
>
>
> Are these scopes a result of user consent ? Or do you need more
> fine-grained control and externalize authorization from my-api ?
>
>
>
> Are you using a specific Keycloak adapter ? (wildfly, spring, etc)
>
>
>
>
>
> Sorry if I’m being unclear.
>
>
>
> Your help is highly appreciated!
>
> Dean
>
>
>
> *Van:* Pedro Igor Silva <psilva at redhat.com>
> *Verzonden:* donderdag 26 juli 2018 14:00
> *Aan:* Wyns Dean <dean.wyns at aptus.be>
> *CC:* keycloak-user at lists.jboss.org
> *Onderwerp:* Re: [keycloak-user] FW: Access control and client setup
>
>
>
>
>
>
>
> On Wed, Jul 25, 2018 at 4:21 AM, Wyns Dean <dean.wyns at aptus.be> wrote:
>
> Hi
>
> I'm evaluating Keycloak as our IAM and SSO and it seems very powerful, but
> I can't seem to wrap my head around some things.
>
> We want to separate our APIs from the IAM. The sole purpose of Keycloak is
> to provide an identity and access token, primarily using the implicit flow.
> The client-side application (usually SPAs) uses the access token in all API
> calls and the resource server checks the signature of the access token but
> does not access Keycloak at all.
>
> Each backend has a few operations, and each operation gets its own
> "permission". For example one API can manage "items", so there are four
> permissions:
> - create:item
> - read:item
> - update:item
> - delete:item
>
> Is it best practice with Keycloak to model these permissions as scopes?
> And then use roles/permissions/policies to limit the scope of the user? The
> backend can then just decode the access token and read the granted scopes.
>
>
>
> Ideally, you should define your authorization settings based on on your
> model. So if you have a resource "Item", which is a protected resource in
> your API you should have a "Item Resource" in Keycloak. The actions/methods
> create, read, update and delete can be scopes associated with your "Item"
> resource.
>
>
>
> Once you have your item resource and scopes, you can define permissions
> that govern access for the resource itself or for each scope individually.
> All depends on how you create those permissions (resource vs scope
> permissions) and policies associated with them.
>
>
>
> The backend could just decode the token and check for the "permissions"
> claim. Or you can also query the Keycloak server on every request to obtain
> a decision.
>
>
>
>
> Also, in a SPA + API set-up, do I create two clients in Keycloak, one for
> each? This is only useful when the API needs resource protection, right? I
> guess in my case I only need one client for the SPA because the API only
> needs the scope from the access token by decoding it.
>
>
>
> I would say you should have two clients representing both applications.
> They have different requirements and are really different things. Your SPA
> is probably a reguar public client while your API is a resource server.
>
>
>
>
> Thanks for any feedback
>
> Kind regards
> Dean
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
>