[Pulp-dev] RBAC Status Thread

[Brian Bouterse]

Today my RBAC work led me to a few conclusions:

1) django admin (the built in django UI) will be the mechanism
administrators use to assign permissions to users and groups. This means
the use of django admin with pulp is very likely (to me).

2) externally defined users and groups will need to be "replicated" to
django's db at login time, probably using headers from the webserver This
is consistent w/ the approach recommended here:
https://www.adelton.com/django/external-authentication-for-django-projects

3) My PoC will include a test ldap running in a docker container and this
solution also should work the same with Active Directory. This picks up two
of the big three (the third being kerberos). I've been following the nginx
reference implementation today to set this up:
https://www.nginx.com/blog/nginx-plus-authenticate-users/


On Wed, Jun 3, 2020 at 5:35 PM Brian Bouterse <bmbouter at redhat.com> wrote:

> Today I got basic object-level permissions experimentally working with
> django-guardian. The current plan is to use a django-guardian to provide
> object-level permissions and drf-access-policy to provide the actual
> authorization checks in the viewset. Django-guardian could provide the
> permission checks in the viewset code itself with decorators, but we
> wouldn't be getting the benefits drf-access-policy provides. It's easy to
> stitch them together to make something great I think. That's what I'll be
> making.
>
> I also talked with @wibbit in the channel yesterday who expressed interest
> in testing the pulp_file PoC. They also confirmed it's basic scope would
> meet their needs.
>
> Also, I got the non standard CRUD permission for "modify_content" working
> for FileRepository using django-guardian.
>
> Lastly I focused on understanding the external users and groups use cases.
> Django has nothing built in for this. This article below suggests to have
> the webserver do it and send along the group info as headers. There are
> third-party libraries ( https://djangopackages.org/grids/g/authentication/
> ) but those are authN specific, so we need to think carefully about what to
> do here.
>
> https://www.adelton.com/django/external-authentication-for-django-projects
>
>
> On Tue, Jun 2, 2020 at 5:07 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
>> I've started experimenting with the basic drf-access-policy example and
>> django-guardian and adapting it to be a RemoteAccessPolicy
>>
>>
>> https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC?expand=1
>>
>> https://github.com/pulp/pulpcore/compare/master...bmbouter:rbac-PoC?expand=1
>>
>> On Mon, Jun 1, 2020 at 5:30 PM Brian Bouterse <bmbouter at redhat.com>
>> wrote:
>>
>>> This thread is where progress made on the RBAC design/implementation
>>> from anyone can be posted. This is designed to bring both transparency and
>>> inclusivity so anyone can get involved on a daily basis.
>>>
>>> Today I outlined a scope of work document -
>>> https://hackmd.io/kZ1oYp8TTkeuC5KL_ffjGQ
>>>
>>> Next tasks:
>>> * test out django-guardian to bring object-level permissions outlined in
>>> SoW doc
>>> * test out drf-access-policy to allow viewset-level permissions
>>> enforcement in SoW
>>>
>>> Feedback and collaboration is welcome.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200605/8ab15db9/attachment.htm>