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 <[email protected]> wrote on 03/15/2015 10:52:31 PM: > From: Jamie Lennox <[email protected]> > To: OpenStack Development Mailing List <[email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
