----- Original Message -----
From: "Ushanas Shastri" <ushanas.shastri(a)viteos.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Charles Henck"
<cjhenck(a)live.com>
Cc: keycloak-user(a)lists.jboss.org
Sent: Thursday, August 18, 2016 4:13:18 AM
Subject: RE: [keycloak-user] Organization Based Accounts and Permissions
Classification: INTERNAL
Hello,
I don’t mean to hijack this thread, but I've had similar requirements, and
would love some advice.
Do you create Resources based on Features (menus in an application) or based
on actual data. For e.g. if Bank Account Maintenance is a feature that
allows you to create/update bank account information, do you create a
Resource in KC for each bank account in the system, and then give
permissions/policies on it, or do you create one Bank Account resource as
indicative of the type Bank Account?
The idea is that you can do both: feature and/or resource.
That is the reason behind our Protection API (based on UMA spec). It provides an API that
allows client applications acting as a resource server (your service) to create
"resources instances" whose owner could be an user. But nothing stops you to
still have a typed resource (eg.: type Bank Account) and apply general
permissions/policies to it. Take a look at that "authz/photoz" example
application, there we try to demonstrate that. There you have a general purpose
"Album Resource" and every time an user creates a new album it is also created a
corresponding resource in the server. In this case, the new resource is going to inherit
the permissions applied to the "Album Resource".
For the feature-based resource scenario, you may take a look to
"authz/servlet-authz-app". There we try to demonstrate how you can protect
resources and actions/scopes in order to build, for instance, a dynamic menu with the
permissions granted by the server.