Open Stack

+1 on passing the raw token along in the environment. That should make it
possible for others to add 3rd party customer filters for additional auth
context manipulation.

We are currently extending/subclassing auth_token middleware to implement
addition security and performance capabilities. Others in the community
may've done something similar. Locking down the auth_token class interface
in crucial in ensuring the stability of the ecosystem. Furthermore, we
should use this opportunity to eliminate technical debts, which means
refactor auth_token middleware to make it more modular, extensible, and
pluggable.


Guang
 

-----Original Message-----
From: heckj [mailto:heckj at mac.com] 
Sent: Wednesday, November 14, 2012 1:47 PM
To: Adam Young; Dolph Matthews
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [KEYSTONE] subclassing auth_token middleware

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_toke
n.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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- 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/20121115/e8d2dee3/attachment.bin>