----- Original Message ----- > From: "Douglas Fish" <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Sent: Wednesday, March 18, 2015 2:07:56 AM > Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new > mechanisms (websso, kerberos, k2k etc) > > > Steve Martinelli <[email protected]> wrote on 03/17/2015 12:52:33 AM: > > > From: Steve Martinelli <[email protected]> > > To: "OpenStack Development Mailing List \(not for usage questions\)" > > <[email protected]> > > Date: 03/17/2015 12:55 AM > > Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth > > for new mechanisms (websso, kerberos, k2k etc) > > > > 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 > > I like proposal 1 better as well. I think the login page is going to need > to reflect information from each of the plugins. I see a start of that > work in the websso work in DOA https://review.openstack.org/#/c/136178 . > It's going to be better for us to define the interface we want for building > the login page elements + showing meaningful error messages on login > failure. > > Doug Fish
Ok, it'll get brought up at the meeting as well (hopefully) but i think you're all correct. Favour composition over inheritance and we can hopefully build a _clean_ new plugin interface. I've brought up to date the proposal 1: https://review.openstack.org/#/c/153910/ Thanks everyone > > __________________________________________________________________________ > 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
