Re: [keycloak-user] Organization Based Accounts and Permissions

Classification: INTERNAL Thank you! I have looked at both examples, and we tried to create resources as being types. Where we're stuck is that we need one additional parameterized context, which we thought we'd achieve by creating client roles. So, the idea is that scope based permissions apply for a given client role. There are no issues setting this up in KC, but the Entitlement API returns a representation that does not combine resource, scopes *and* client roles. It combines resources and scopes, but client roles are a separate list. The JSON (a part of it) looks like this "resource_access": { "servlet-authz-app": { "roles": [ "Setup1", "Setup2" ] } }, "authorization": { "permissions": [ { "scopes": [ "view" ], "resource_set_id": "35750d56-d32a-4106-8b63-882e998ec545", "resource_set_name": "Account Setup" }, { "scopes": [ "view" ], "resource_set_id": "11389916-6cac-41af-95f1-8409019a84b3", "resource_set_name": "Investor Setup" } ] } The way its setup, is that this user can do view scope for resource "Account Setup" for only client role "Setup1", and cannot do scope view for resource "Account Setup" for client role "Setup2". If the authorization property put relevant client roles inside permissions, it would do everything we needed. Regards, Ushanas. Viteos Fund Services Ltd | www.viteos.com Direct : +91-22-61082230 | US : +1- 888-821-7561 extn 240 Cell : +91-9820225580 Email : ushanas.shastri(a)viteos.com -----Original Message----- From: Pedro Igor Silva [mailto:psilva@redhat.com] Sent: Thursday, August 18, 2016 5:25 PM To: Ushanas Shastri Cc: Charles Henck; keycloak-user(a)lists.jboss.org Subject: Re: [keycloak-user] Organization Based Accounts and Permissions ----- Original Message ----- 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. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Viteos Capital Market Services Ltd.and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity