Open Stack

On Tue, 2012-11-13 at 21:50 +0000, Joe Heck wrote:
> Guang brought up the same need (and I think his team at HP is alrealdy
> doing it) - so I wanted to get some feedback on the contracts that you
> (Kevin & Guang) are after to support making auth_token something
> that's stable enough to be subclassed (and to nail down those
> interfaces so we don't accidentally break them in the future). What
> hooks or methods do your needs for subclasses have today?

What I particularly care about is certain extension data that may be
included in the token verification response.  What I'm after with my
review (https://review.openstack.org/#/c/16002) is to make that data
available to another piece of middleware following auth_token in the
WSGI stack; this other piece of middleware would translate that
extension data into particular headers (as well as make some more calls
to our in-house version of Keystone to pick up some other important
data).  I chose this route because it allows me to avoid having to
either write my own auth_token middleware or having to maintain a set of
patches to auth_token in-house.  I admit that directly subclassing the
middleware did not occur to me, but it's not clear that the current
design of the middleware lends itself to that.

> Guang mentioned how keystone handles EC2 token validation today -
> perhaps breaking auth_token middleware into two separate filters,
> token_validator and context_builder.

I think such a breakdown would provide an alternate solution to my
problem; however, we need to think carefully about it.  One of my other
important concerns is some header sanitizing, for instance; I have
several headers that I would add that need to be stripped out of the
incoming request, not to mention some other headers that simply need to
be removed.  In one case, the best way to describe the headers that need
to be stripped is with a wildcard, i.e., all headers that start with a
particular string.

As I say, the above breakdown would work fine; however, I thought I'd
also suggest another approach: some way to incorporate plugins into the
sequence.  That is, you could have some optional configuration option to
substitute out the token validation, and some other one—perhaps an
iter_entry_points()-based loop—that would perform the context building.
(I don't necessarily think that this is a good approach, I'm just laying
it out there for other people to brainstorm with.)
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>