[openstack-dev] [KEYSTONE] subclassing auth_token middleware

heckj heckj at mac.com
Wed Nov 14 21:46:31 UTC 2012


Adam, Dolph - 

I'd like you two to weigh in here a bit as keystone-core please. 

The operational question is how (I'm assuming that "IF" is already a yes), with the auth_token middle, do we want to support the ability to pass along arbitrary additional data from a token authorization response to downstream applications. If we like the idea of popping that data into HTTP Headers and flowing them with the request down the pipe like we do with the authorization information, then I'm good with Kevin's review (pending tests to verify the functionalty).

The other path that seemed to me to be available was to otherwise populate up the env from __call__ that gets passed down (which includes the HEADERS).

The second option is to assert that auth_token is *ONLY* responsible for asserting auth, asking Kevin to create his own middleware piece that plugs into the pipeline. This seems a bit suboptimal since it would mandate a second request to Keystone to get the relevant information from the token (outside of the PKI tokens, which have all that data included *as* the token).

Doing something within auth_token to accept and pass data consistently through the token into the WSGI environment is desired.

-joe



On Nov 14, 2012, at 10:47 AM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
> On Wed, 2012-11-14 at 17:33 +0000, Yee, Guang wrote:
>> Yes WSGI pipeline. How else are you intend to use auth_token middleware?
>> 
>> Looking at the changes
>> 
>> https://review.openstack.org/#/c/16002/1/keystoneclient/middleware/auth_token.py
>> 
>> You are basically setting the extensions data in the headers right?
>> You should be able to sanitize the X_<USER|TENANT|TOKEN>_EXTENSION
>> headers in header_sanitizer and set them in your own extension context
>> builder. What am I missing?
> 
> I have gotten somewhat confused.  16002 is my review and was the
> approach I was shooting for, but heckj pushed back on that and brought
> it to the list to see if there were suggestions on other possible
> implementations; I had thought his suggested implementation was to
> subclass the auth_token middleware and try to solve my problem that way.
> 
> If we like 16002, I'm quite happy with that approach; I can do
> everything I need to do by just implementing one more piece of
> middleware.  If that's not a desirable approach, I can suggest that we
> stuff the entire token validation response into the wsgi environment
> (not a header), which would also meet my needs.  If we want to use a
> subclassing approach, we need some further modification to the existing
> auth_token middleware to make that work, but that basically amounts to
> some refactoring, and I should again be able to make that work.  I just
> need to know which approach we are going to end up taking in the end :)
> -- 
> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list