Open Stack

Sure, we can have a generic header_sanitizer filter sitting in front of token_validator so the pipeline would look something like this

... header_sanitizer token_validator context_builder <3rd party context builder> ...


header_sanitizer: removes the given set of headers from the request. Headers to be removed are configured in the filter section.
token_validator: does token caching (including cache encryption) if necessary; validates the token using a set of configurable protocols (i.e. http, https, pki, etc); and sets the raw token in the environment.
context_builder: builds the default Keystone context from the raw token by setting the X_USER_ID, X_TENANT_ID headers, etc.
<3rd party context builder>: additional header/environment manipulation


We should have a "contrib" folder in python-keystoneclient to stash the 3rd party middlerware filters. When a 3rd party middleware filter becomes mainstream, we'll promote it to core/default in the next release.


Guang


-----Original Message-----
From: Kevin L. Mitchell [mailto:kevin.mitchell at rackspace.com] 
Sent: Tuesday, November 13, 2012 2:52 PM
To: Joe Heck
Cc: Yee, Guang; Dolph Matthews; Adam Young; OpenStack Development Mailing List
Subject: Re: [KEYSTONE] subclassing auth_token middleware

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/76327c5e/attachment.bin>