[keycloak-dev] fine-grain admin permissions with Authz

[Pedro Igor Silva]

On Mon, Mar 13, 2017 at 12:15 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 3/13/17 9:43 AM, Pedro Igor Silva wrote:
>
>
> Are you already implementing things ? Do you want me to look at these
> changes or work together with you on them ?
>
> (As you may have noticed, there is an API that we use internally to
> actually evaluate policies given a set of permissions.)
>
> Haven't implemented anything just researching how it could be done.  The
> biggest issue right now that I'm having is that I don't understand how to
> do things programatically yet (i.e. set up resources, set up scopes, set up
> permissions, set up policies).  I don't understand how the UI translates to
> the JPA entity model and there seems to be a lot of set up data hidden by
> generic Map objects.  Its also really confusing how the admin REST
> interface translates from the UI to the model.    Its also really bizarre
> to me that the things represented in the Admin Console UI are not
> represented in the data model.  i.e. I have no idea how a
> "Scoped-Permission" in the admin console maps to a JSON representation, the
> REST API, nor how that JSON representation is mapped to the model.
>

The usage of Map objects is similar to what we have with identity
brokering. We need to be flexible in order to support different types of
policies without requiring changes to model.

Regarding representation, both permission and policy are represented as
policies. What differs a permission from a policy is the type. Policies
defined as "scope" or "resource" (as you have in UI) are the ones you can
use to actually create permissions to resources and scopes.

Everything you need is available from an AuthorizationProvider instance,
which can be obtained as follows:

    KeycloakSession.getProvider(AuthorizationProvider.class);

>From an instance of that class you can access methods to evaluate
permissions or obtain references to the different storages we use to
actually manage resources, policies, scopes and resource servers. I can
include the AuthZ API as a topic to our meeting about authz services next
week.

Regarding scope-based permissions and the use cases you pointed out, I
think we may have to change how we are handling typed resources. Today, we
know a resource is a general/typed resource because the owner of the
resource is the resource server itself, and resource instances are usually
owned by an user, someone different than the resource server. Need to take
a look on this one and see how it impact the use cases you pointed out ...


>
>
> BIll
>