Open Stack

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.

Thanks,

Steve Martinelli
OpenStack Keystone Core

Jamie Lennox <jamielennox at redhat.com> wrote on 03/15/2015 10:52:31 PM:

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