Open Stack

On Thu, 2012-11-15 at 12:19 -0500, Adam Young wrote:
> I think it complicates things.  I'd rather use the auth token headers we 
> have, or focus on heading back toward standard headers.

The application I'm working on is an internal application, and I really
need the extension data from the verification response.  I really don't
care how I get it—these extension headers I propose in 16002 will work
fine, as would putting the verification response into the WSGI
environment or even rearchitecting auth_token.py to be easier to
subclass.  I just need the data, and 16002 seemed like the least-cost
means of getting it at the time.

> However, you do bring up an interesting use case: offloading the token 
> validation does make sense in some setups, and I am not sure how we 
> would want to tie in with the WSGI spec in those cases.  My suspicion is 
> that there is a better way than customer headers.  If, for example, 
> someone had already done the LDAP lookup for groups (AuthZ) in a 
> Kerberos (AuthN) implementation,  that information gets filtered at the 
> Proxy. I don't know of a standard way of passing that information on the 
> the WSGI App.  Have you done the research to show that there is not good 
> way to do this?

Have I done any research on what headers people are using for
transferring authentication results?  No; so far as I know, there is no
spec for that.  Further, we're talking about a protected path (between a
proxy and the final backend implementation), so it's not 100% clear to
me that we need a standard as developed by someone else; I think our use
of x-user-id, x-user-name, x-tenant-id, x-tenant-name, etc. is perfectly
acceptable for this, and valid as a spec.  (In fact, I know of no other
system that even has the concept of a tenant/user division, though that
makes absolutely perfect sense in our use case.)  The only real question
is, what about people that need to include other, internally-derived
data through that protected path?  How can they get access to extended
information included in the verification response?  How they inject it
into the protected path should be up to them, but they need to get to
that data, and that's where the conversation came from…
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>