On 3/13/17 11:49 AM, Pedro Igor Silva wrote:
On Mon, Mar 13, 2017 at 12:15 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@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.
This is the really confusing part. There is no documentation on how to
set up a Scoped or Resource permission through the REST API. The
AuthzClient only allows you to create resources AFAICT. I'm currently
tracing through admin-console permission UI to find which REST endpoint
to use, and how that REST endpoint converts JSON into actual API calls.
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.
I don't have everything I need as you overload concepts (permission and
policy) and it doesn't make sense yet the magic that must be done to
store these definitions.
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 ...
I have no idea what you're talking about
here. Am I missing something
fundamental here? From the docs, examples, and the admin console UI, I
thought Authz was about defining rules (policies) to determine if
somebody is allowed to perform a specific action (scope) on a certain
thing (resource).
Bill