[openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)

Jamie Lennox jamielennox at redhat.com
Mon Mar 16 02:52:31 UTC 2015


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





More information about the OpenStack-dev mailing list