[Web-SIG] Communicating authenticated user information

[Alan Kennedy]

[Jim Fulton]
 >>>Is Zope the only WSGI application that performs authentication
 >>>itself?

[Phillip J. Eby]
 >>I think Zope is the only WSGI application that cares about
 >> communicating this information back to the web server's logs.  :)

[Jim Fulton]
 > I hope that's not true.  Certainly, if anyone else is doing
 > authentication in their applications or middleware, they
 > *should* care about getting information into the access logs.

Well, Apache records auth info in logs as well, and it seems like a 
perfectly reasonable thing for a server to do .....

http://httpd.apache.org/docs/2.0/logs.html#accesslog

[Phillip J. Eby]
 >> Perhaps an "X-Authenticated-User: foo" header could be added
 >> in a future spec version?  (And as an optional feature in the
 >> current PEP.)

[Jim Fulton]
 > Perhaps. Note that it should be clear that this is soley for use
 > in the access log.  There should be no assumption that this is
 > a principal id or a login name.  It is really just a label for the
 > log.  To make this clearer, I'd use something like:
 > "X-Access-User-Label: foo".

Sending X-headers seems hacky, and results in unnecessary information 
being transmitted back to the user (possibly revealing sensitive 
information, or opening security holes?)

I think that the communication mechanism for auth information is 
possibly best served by a simple convention between auth middleware 
authors. Perhaps servers that are aware that auth middleware is in use 
can put a callable into the WSGI environment, which auth middleware 
calls when it has auth'ed the user?

[Phillip J. Eby]
 > This seems a simpler way to incorporate the feature than adding
 > an extension API to environ.

[Jim Fulton]
 > Why is that?  Isn't the env meant for communication between
 > the WSGI layers?  I'm not sure I'd want to send this information
 > back to the browser.

I think an API could be very simple, and optional for servers that know 
they won't be logging auth information.

I agree about not sending this information back to the user: it's 
unnecessary and potentially dangerous.

Regards,

Alan Kennedy.