Open Stack

----- Original Message -----
> From: "Douglas Fish" <drfish at us.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> 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 <stevemar at ca.ibm.com> wrote on 03/17/2015 12:52:33 AM:
> 
> > From: Steve Martinelli <stevemar at ca.ibm.com>
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > <openstack-dev at lists.openstack.org>
> > 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 <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
> > >
> __________________________________________________________________________
> > 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
> 
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>