<font size=2 face="sans-serif">I like proposal 1 better, but only because
I am already familiar with how plugins interact with keystoneclient. The
websso work is (i think) pretty close to getting merged, and could easily
be tweaked to use a token plugin (when it's ready). I think the same can
be said for our k2k issue, but I'm not sure.</font>
<br><font size=2 face="sans-serif"><br>
Thanks,<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Core</font>
<br>
<br><tt><font size=2>Jamie Lennox <jamielennox@redhat.com> wrote
on 03/15/2015 10:52:31 PM:<br>
<br>
> From: Jamie Lennox <jamielennox@redhat.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org></font></tt>
<br><tt><font size=2>> Date: 03/15/2015 10:59 PM</font></tt>
<br><tt><font size=2>> Subject: [openstack-dev] [Horizon][DOA] Extending
OpenStack Auth for<br>
> new mechanisms (websso, kerberos, k2k etc)</font></tt>
<br><tt><font size=2>> <br>
> Hi All, <br>
> <br>
> Please note when reading this that I have no real knowledge of django
so<br>
> it is very possible I'm overlooking something obvious.<br>
> <br>
> ### Issue<br>
> <br>
> Django OpenStack Auth (DOA) has always been tightly coupled to the<br>
> notion of a username and password.<br>
> As keystone progresses and new authentication mechanisms become<br>
> available to the project we need a way to extend DOA to keep up with
it.<br>
> However the basic processes of DOA are going to be much the same,
it<br>
> still needs to fetch an unscoped token, list available projects and<br>
> handle rescoping and this is too much for every extension mechanism
to<br>
> reimplement.<br>
> There is also a fairly tight coupling between how DOA populates the<br>
> request and sets up a User object that we don't really want to reuse.<br>
> <br>
> There are a couple of authentication mechanisms that are currently
being<br>
> proposed that are requiring this ability immediately.<br>
> <br>
> * websso: </font></tt><a href=https://review.openstack.org/136178><tt><font size=2>https://review.openstack.org/136178</font></tt></a><tt><font size=2><br>
> * kerberos: </font></tt><a href=https://review.openstack.org/#/c/153910/><tt><font size=2>https://review.openstack.org/#/c/153910/</font></tt></a><tt><font size=2>
(patchset 2).<br>
> <br>
> and to a certain extent:<br>
> <br>
> * k2k: </font></tt><a href=https://review.openstack.org/159910><tt><font size=2>https://review.openstack.org/159910</font></tt></a><tt><font size=2><br>
> <br>
> Enabling and using these different authentication mechanisms is going
to<br>
> need to be configured by an admin at deployment time.<br>
> <br>
> Given that we want to share the basic scoping/rescoping logic between<br>
> these projects I can essentially see two ways to enable this.<br>
> <br>
> ### Proposal 1 - Add plugins to DOA<br>
> <br>
> The easiest way I can see of doing this is to add a plugin model to
the<br>
> existing DOA structure.<br>
> The initial differentiating component for all these mechanisms is
the<br>
> retrieval of an unscoped token.<br>
> <br>
> We can take the existing DOA structure and simply make that part<br>
> pluggable and add interfaces to that plugin as required in the future.<br>
> <br>
> Review: </font></tt><a href=https://review.openstack.org/#/c/153910/><tt><font size=2>https://review.openstack.org/#/c/153910/</font></tt></a><tt><font size=2><br>
> <br>
> Pros:<br>
> <br>
> * Fairly simple and extensible as required.<br>
> * Small plugin interface.<br>
> <br>
> Cons:<br>
> <br>
> * Ignores that django already has an authentication plugin system.<br>
> * Doesn't work well for adding views that run these backends.<br>
> <br>
> ### Proposal 2 - Make the existing DOA subclassable.<br>
> <br>
> The next method is to essentially re-use the existing Django<br>
> authentication module architecture.<br>
> We can extract into a base class all the current logic around token<br>
> handling and develop new modules around that.<br>
> <br>
> Review: </font></tt><a href=https://review.openstack.org/#/c/164071/><tt><font size=2>https://review.openstack.org/#/c/164071/</font></tt></a><tt><font size=2><br>
> An example of using it:<br>
> </font></tt><a href="https://github.com/jamielennox/django-openstack-auth-kerberos"><tt><font size=2>https://github.com/jamielennox/django-openstack-auth-kerberos</font></tt></a><tt><font size=2><br>
> <br>
> Pros:<br>
> <br>
> * Reusing Django concepts.<br>
> * Seems easier to handle adding of views.<br>
> <br>
> Cons:<br>
> <br>
> * DOA has to start worrying about public interfaces.<br>
> <br>
> ### Required reviews:<br>
> <br>
> Either way I think these two reviews are going to be required to make<br>
> this work:<br>
> <br>
> * Redirect to login page: </font></tt><a href=https://review.openstack.org/#/c/153174/><tt><font size=2>https://review.openstack.org/#/c/153174/</font></tt></a><tt><font size=2>
- If<br>
> we want apache modules to start handling parts of auth we need to
mount<br>
> those at dedicated paths, we can't put kerberos login at /<br>
> * Additional auth urls: </font></tt><a href=https://review.openstack.org/#/c/164068/><tt><font size=2>https://review.openstack.org/#/c/164068/</font></tt></a><tt><font size=2>
- We<br>
> need to register additional views so that we can handle the output
of<br>
> these apache modules and call the correct authenticate() parameters.<br>
> <br>
> ### Conclusion<br>
> <br>
> Essentially either of these could work and both will require some<br>
> tweaking and extending to be useful in all situations.<br>
> <br>
> However I am kind of passing through on DOA and Django and would like<br>
> someone with more experience in the field to comment on what feels
more<br>
> correct or any issues they see arising with the different approaches.<br>
> Either way I think a clear approach on extensibility would be good<br>
> before committing to any of the kerberos, websso and k2k definitions.<br>
> <br>
> <br>
> Please let me know an opinion as there are multiple patches that will<br>
> depend upon it.<br>
> <br>
> <br>
> Thanks,<br>
> <br>
> Jamie<br>
> <br>
> <br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>