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

Tue Jul 31 08:05:28 EDT 2018

On Tue, Jul 31, 2018 at 3:58 AM, Wyns Dean <dean.wyns at aptus.be> wrote:

> Hi Pedro
>
>
>
> Thanks for the clarification.
>
>
>
> The scopes are not really a result of user concent, but rather just a
> request for the right amount of permissions.
>
> A user can ask for as much permission he needs by using the scope. So if
> the SPA needs read and create permission for items, the scope can be
> “openid read:items create:items”. If the user can only read items,
> eventually the resulting scope should be “openid read:items” and the
> backend can block create calls.
>
> I saw some people create roles for every scope and then use composite
> roles to for example create “admin” users with the right roles for the
> scopes. Is this the right way to do this?
>
>
>
> An item is assigned to a customer (and a user is assigned to a customer),
> so my-api still needs to filter on that so that users can only read items
> from their own customer. Is this a use case where the fine-grained
> authorization of Keycloak comes into play? We’d need to create an item
> resource in Keycloak for every item in our database, right? And then use
> UMA to check the access to a particular item?
>

I think UMA does not fit as it seems you don't need users managing their
resources. In this case you could have a single resource in Keycloak and
configure my-api to send claims to the server when obtaining permissions
from server. These claims would provide the necessary information that your
policies should consider when evaluating permissions to a general resource
in Keycloak representing all your items.

>
>
> We could also just add the customer as a claim in the token and use that
> to filter our database (but like you said then my-api does the
> authorization). I think this is the way to go for our case at the moment,
> as we already have an existing system where it happens like this. So it
> requires minimal refactoring.
>

Filter records in a database is not among the use cases we are considering,
but API security and privacy (through UMA).  I'm not saying that is not
possible, but that would require network calls to the server to check
permissions to each item returned from your database. Best is filter data
when querying database ...

However, if after filtering these resources (by customer) you have specific
authorization requirements around what you can do in particular item or
even if the user is allowed to access some part of your API, then you could
use fine-grained permissions and easily externalize these authz decisions
from your app.

>
>
> As of now, we’re not using any adapters yet. Most of our backend processes
> are in Node.js btw. But we’re also checking out Kong as an API gateway to
> use, so we could use an OIDC plugin that communicates with Keycloak if
> needed.
>
>
>
> Thanks a lot
>
> Dean
>
> *Van:* Pedro Igor Silva <psilva at redhat.com>
> *Verzonden:* maandag 30 juli 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
>
>
>
>
>