<div dir="ltr"><div># ldap PoC updates</div><div>Now users, groups, and group membership are populating from ldap automatically on login (with auth backed by ldap also)! I'll be sharing my configs for both ldap and how to configure <a href="https://django-auth-ldap.readthedocs.io/en/latest/example.html">django-auth-ldap</a> here soon in an organized way. This was done with django-auth-ldap and 0 customization to pulp code. It's 100% enabled through settings so this work is more of an approach we can document for users that they can enable and not a feature Pulp ships itself.<br></div><div><br></div><div># django-admin progress</div><div>Thanks to @alikins existing PRs, I got django admin enabled and able to view/edit users, groups, group membership, and permissions at both the user and group levels. This is important because this will be the primary mechanism of administrators. This part is looking good.<br></div><div><br></div><div># new resources to help us out</div><div>Through collaboration with @ttereshc and someone off list named @adelton (who actually authored <a href="https://www.adelton.com/django/external-authentication-for-django-projects">this reference approach</a> I referenced early on in this exploration), this very cool repository of testing tools was identified: <a href="https://github.com/adelton/webauthinfra">https://github.com/adelton/webauthinfra</a> It has a treasure trove of testing containers which Pulp devs in the future can test against. It keeps the user/group check in the apache which is fine alternative to the django-auth-ldap approach above. Pulp doesn't have to choose, it could work with either just configured differently. The pending PoC outline will go over these alternative approaches in detail.<br></div><div><br></div><div># Next Steps: back to the PoC itself</div><div>Now that we have demonstrated good options of external users/groups/membership loading into Pulp we can confidently move back to finishing the RBAC PoC itself. I've started back into this. So the remaining work are the two steps below:</div><div><br></div><div>1. Finish the PoC that uses RBAC to restrict remotes, sync, and repository content modification. Currently I prototyped restriction of operations on Remotes, but I need to replicate the access policies to Repositories and Sync next.</div><div>2. Write it up and share it.</div><div>3. Schedule public meeting to review it (targeting next-week)<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 19, 2020 at 5:09 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I got the LDAP users both authenticating and importing into Pulp! Next I'll do the groups and then I think the ldap parts will be done.<br></div><div><br></div><div>FYI: I'm going to write up the implementation design and have that come with this proof of concept code . This will let us know what choices it makes, why it makes them, and we can determine if these are the right choices together.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 4:57 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I got a lot further on this today. I have the test ldap setup with several test users and groups. I have django-auth-ldap configured mostly authenticating username/password against ldap instead of the internal database first. Once that is fully working the users will auto-populate into django and the groups should follow easily.</div><div><br></div><div>Once that's done I'll be unblocked to finish the RBAC PoC. The rest of the parts are straightforward given the testing I've already done. More updates to come.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 5:03 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I got the ldap reference implementation performing auth really nicely against a test ldap with this guide: <a href="https://www.nginx.com/blog/nginx-plus-authenticate-users/" target="_blank">https://www.nginx.com/blog/nginx-plus-authenticate-users/</a> Now there are some new challenges though:<br></div><div><br></div><div>* Great that we can auth users, but we need nginx to extract-and-forward the group information to Pulp itself. That way a middleware can create the user AND group info in the backend.</div><div>* we have to figure this out all again in Apache...</div><div><br></div><div>Maybe we should be integrating Pulp directly against django-auth-ldap [0]. I am going to try that next. The work I've done isn't 100% reusable there, but most of it is because the test server and configs I used can all be reused directly with django-auth-ldap. The concern with this approach is that we would be supporting LDAP (and transitively Active Directory) but are there other directory services Pulp needs to support?<br></div><div><br></div><div>I also emailed Bin Li asking for info on how their user and group management works.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 11:48 AM Adrian Likins <<a href="mailto:alikins@redhat.com" target="_blank">alikins@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 5, 2020 at 8:23 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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).<br></div><div><br></div></div></blockquote><div>Hopefully <a href="https://github.com/pulp/pulpcore/pull/705" target="_blank">https://github.com/pulp/pulpcore/pull/705</a> will be useful here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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: <a href="https://www.adelton.com/django/external-authentication-for-django-projects" target="_blank">https://www.adelton.com/django/external-authentication-for-django-projects</a></div></div></blockquote><div><br></div><div>This is more or less what galaxy_ng ends up doing, at least for the scenarios where it runs hosted with external SSO. </div><div><a href="https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/app/auth/auth.py#L51" target="_blank">https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/app/auth/auth.py#L51</a> for example. </div><div> </div></div></div> </blockquote></div> </blockquote></div> </blockquote></div> </blockquote></div>