On 3/13/17 1:27 PM, Pedro Igor Silva wrote:
On Mon, Mar 13, 2017 at 2:10 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
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.
The confusion is because we have this JIRA
https://issues.jboss.org/browse/KEYCLOAK-3135. Currently, we don't
have a nice REST API for policy management. That explains why we lack
docs as well. You can use KC Admin Client (that is what we use in
tests) but that will change once we introduce a specific API for this
purpose.
> 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.
I don't think I've overloaded concepts. The concept of a policy is
much more broader than with a permission. A policy can be seen as a
condition that must be satisfied in order to grant/deny access to
something (resource or scope). You can reuse policies across different
permissions (you probably want that instead of replicating the same
condition on similar policies), policies can be combined to form more
complex and fine-grained conditions (see aggregated policies), etc.
I'm sorry. I sounded too critical and I didn't mean to be or sound like
I was attacking you. I really like what you are doing and am excited
about it...but...You do overload concepts because the admin console has
the concept of a Permission and there's no Permission object in the REST
API, the model api, or the data model. Permission looked like a join
table between Resource and Policy or Resource, Scope, and Policy. From
your docs and admin console it looks like you have 4 concepts:
* The thing (Resource)
* The action (scope)
* The condition (policy)
* The permission (join of resource, scope, and policy).
On the other hand, permissions are what you actually use to say: "OK,
here is the thing I want to protect with these policies". Initially,
we didn't have the "permission" concept at all and that was blocking
us to be more flexible and support more functionalities.
Yeah, Keycloak didn't have the concept of "Resource",
"Scope", or
"Policy". Role was really just a way to catagorize users. Is that
what you mean?
What magic you are talking about ?
> 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).
There are a few things more than just "are you allowed to do this" :)
You may get to a decision in different/configured ways. Glad that you
are now looking into this.
What is the more? I understand you can get to a decision in different
ways. That's what is really cool about your stuff...but what exactly
are you "deciding" on? Again I thought we were deciding what actions
can somebody perform on a resource.
Some other related questions:
* What is a "resource permission" supposed to be? Is it a "catch all"
for that resource?
* What if you have multiple "scoped permissions" defined for the same
resource and scope. Do they all have to be true? Or just one?
What I meant is that we kind of support a parent/child relationship
between resources with typed resources [1]. Just thinking loud about
what we may (or not) need to use authz internally.
[1]
https://keycloak.gitbooks.io/authorization-services-guide/topics/permissi...
That looks interesting, but there's currently no way to say: For this
resource type and these scopes, apply these policies. The "scope" part
is missing.
Bill