[katello-devel] - On authorization

Wed Aug 17 06:25:21 UTC 2011

On 08/17/2011 04:53 AM, Partha Aji wrote:
>
> ----- Original Message -----
>> From: "Partha Aji"<paji at redhat.com>
>> To: "Ivan Nečas"<inecas at redhat.com>
>> Cc: katello-devel at redhat.com
>> Sent: Tuesday, August 16, 2011 10:43:28 PM
>> Subject: Re: [katello-devel] - On authorization
>> ----- Original Message -----
>>> From: "Ivan Nečas"<inecas at redhat.com>
>>> To: "Bryan Kearney"<bkearney at redhat.com>
>>> Cc: katello-devel at redhat.com
>>> Sent: Tuesday, August 16, 2011 11:42:33 AM
>>> Subject: Re: [katello-devel] - On authorization
>>> On 08/16/2011 04:43 PM, Bryan Kearney wrote:
>>>> On 08/16/2011 09:34 AM, Ivan Nečas wrote:
>>>>> On 08/16/2011 02:53 PM, Bryan Kearney wrote:
>>>>>> On 08/16/2011 05:50 AM, Ivan Nečas wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm working on authorization for CLI and I would like to make
>>>>>>> some
>>>>>>> discussion about it. The current state in UI is the following
>>>>>>> (correct
>>>>>>> me, if there are some mistakes):
>>>>>>>
>>>>>>> The main unit for authorization is resource type (e.g.
>>>>>>> provider,
>>>>>>> organization) + verb (create, update, delete, read,...). In UI,
>>>>>>> before
>>>>>>> each request (in before_filter) there is check, whether
>>>>>>> the user has permission on the given verb for the given
>>>>>>> resource
>>>>>>> type.
>>>>>>> The resource type is derived directly from the controller. The
>>>>>>> verb is
>>>>>>> translated from action name, the map for the translations is in
>>>>>>> Role::ACTION_TO_VERB and Role::DEFAULT_VERBS respectively.
>>>>>> This was the original plan... a simply applicatoin of type to
>>>>>> and
>>>>>> verb
>>>>>> However, I believe the work that Justin and Partha did brought
>>>>>> the
>>>>>> level up. So.. we still have types and verbs, however things
>>>>>> like
>>>>>> "creating an environment" would be governed by the ability to
>>>>>> modify
>>>>>> the org.
>>>>>>
>>>>>>> This brings few problems:
>>>>>>>
>>>>>>> 1. storing information about controller in the model - may lead
>>>>>>> to
>>>>>>> problems, such as: we create new action, but forget to add
>>>>>>> translation
>>>>>>> to Role model. To have it by the action would be better
>>>>>>>
>>>>>>> 2. the controller is tied to the resource - in API, we have
>>>>>>> OrganizationController#providers action. In current state, it
>>>>>>> would
>>>>>>> check permissions on organization resource. I think permissions
>>>>>>> on
>>>>>>> provider resource should be checked instead. I agree that have
>>>>>>> resource
>>>>>>> related actions in it's controller could be better, but it's
>>>>>>> quite
>>>>>>> limiting sometimes.
>>>>>> see above on this, I believe we are looking towards a smaller
>>>>>> set
>>>>>> of
>>>>>> coarse grained checks.
>>>>>>
>>>>>>> 3. checking against one resource - we might want to check e.g.
>>>>>>> wheter
>>>>>>> user has right to read organization and provider for
>>>>>>> OrganizationController#providers. In current implementation we
>>>>>>> can't do
>>>>>>> this.
>>>>>>>
>>>>>>>
>>>>>>> Idea: Use meta-programming features in Ruby, to achieve
>>>>>>> annotations -
>>>>>>> something, like this:
>>>>>>>
>>>>>>> OrganizizationController<  Api::ApiController
>>>>>>>
>>>>>>> require_permission :providers, :read
>>>>>>> require_permission :organization, :read
>>>>>>> def providers
>>>>>>> # ...
>>>>>>> end
>>>>>>>
>>>>>>> end
>>>>>>>
>>>>>>> What do you think about this approach? I've done something
>>>>>>> similar
>>>>>>> before, so there should not be problem with the implementation.
>>>>>> I would be fine with this if it allows us the granularity we
>>>>>> need.
>>>>>>
>>>>>>> It could also detect, if some action is not mapped to
>>>>>>> resource+verb -
>>>>>>> either on the start-up time or with some rake task.
>>>>>>>
>>>>>> -- bk
>>>>> Ok, thanks for update info - my thoughts were based on the master
>>>>> branch, but there is a roles-ui branch I haven't notice before,
>>>>> where
>>>>> the situation is quite different. I will discuss with Justin the
>>>>> best
>>>>> approach. Anyway, the DSL can be compatible with the updated work
>>>>> as
>>>>> well, so the granularity would be preserved.
>>>>>
>>>>> Ivan
>>>>>
>>>> Putting my schedule cap on. Simple is good :)
>>>>
>>>> --bk
>>>>
>>> Ok, I've put a possible solution to origin/roles-cli. The only think
>>> it
>>> needs in the controller is
>>>
>>> include ActionAuthRules
>>>
>>> and before given action:
>>>
>>> add_auth_rule(:providers, :read, :organizations)
>>> add_auth_rule(:providers) { Provider.any_readable?(@organization) }
>>> def providers
>>> # ...
>>> end
>>>
>>> You can add more rules - all rules must satisfy to be authorized.
>>> You can use block, or allowed_to?-like arguments for each rule.
>>>
>>> Any objections to this approach?
>>>
>>> -- Ivan
>>>
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>> Your approach sound interesting but I don't see your branch in
>> katello.git.
>> Check if you have pushed your changes on to the remote branch and let
>> me know..
>>
>> Partha
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
> Also if you looked at the roles-ui branch. One of the ideas is to actually loading an object
> before you ask if its readable by the user. look at the rules method of
> http://git.fedorahosted.org/git/?p=katello.git;a=blob;f=src/app/controllers/providers_controller.rb;h=9c0c32d19d55c32e7bbe9705566c8847566df0a0;hb=roles-ui
>
>    read_test = lambda{@provider.readable?}
>
> The read_test assumes that the provider instance is loaded before asking if its readable by the current user.
> And that instance gets loaded in find_provider filter call. What I am trying to ask/suggest is that
> the rules check must happen after the find_provider call happens (I don't know if thats is possible with your approach).
> May be its no biggie. May be we can do something like
>
> add_auth_rule(:providers,:read) { p = Provider.find(params[:id]); p.readable?}
It's not necessary - it works exactly the same, as the lambda approach - 
the only think to remeber is to include ActionAuthRules after 
before_filter-s in the controller, so that the filter that actually 
checks the authorization is executed after them.

So this is works:

add_auth_rule(:providers ) { @provider.readable? }

In your example, you used combined args and block - In my current implementation, you can specify one of them - but it can be changed.

The first argument is the name of the action, not resource: add_auth_rule(action, verb, resource), but I got a feeling, that we are leaving using this approach in favour of .any_readable?-like methods.

>
> Anyway let me know once you push your branch..
Sorry for that - I forgot the "-n" parameter, when I was checking 
everything goes fine before actual pushing. I should be in the repo now.
>
> Partha
>
>
>

-- Ivan