Open Stack

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