[keycloak-user] Organization Based Accounts and Permissions

[Pedro Igor Silva]

----- Original Message -----
> From: "Ushanas Shastri" <ushanas.shastri at viteos.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Charles Henck" <cjhenck at live.com>
> Cc: keycloak-user at 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.