web2/scgi authentification with REMOTE_USER and Cred

[boga]

The REMOTE_USER environment variable is not passed through the cgi modules. (I'm 
interested in scgi). REMOTE_USER contains the authenticated user name, if apache 
authenticated one.

I'd like to use scgi and REMOTE_USER authentication with Zope3. With the patches  
attached i was able to get REMOTE_USER available as a part of the request 
header. 

[The patches not 100% ok, as the real variable passed to Zope3 WSGI handler was 
HTTP_REMOTE_USER. But when asking Zope3 for header value of REMOTE_USER it 
searched the HTTP_REMOTE_USER as well, so this is working fine in Zope3 
environment.]

Look for REMOTE_USER at http://httpd.apache.org/docs/1.3/mod/mod_cgi.html.

[jknight]

Hm, I'd like to fix this a different way, so that it can work with internal 
authentication as well. Also, it sounds like there's a security issue if Zope3 
is searching for HTTP_REMOTE_USER. That will allow an enduser to set the HTTP 
header "Remote-User" in their incoming request and pretend to be whomever they 
want. Using HTTP_ names for computed auth info is not good.

The incoming REMOTE_USER should be decoded into an appropriate auth object and 
stored. Then, the outgoing cgi encoding process should be able to take the 
username and authtype from this auth object and put them into REMOTE_USER/
AUTH_TYPE. If authentication was done internally, the outgoing part works the 
same, because the auth object was just attached internally.

[boga]

Attached a new version of the patch that fixes the HTTP_REMOVE_USER issue. 
Thanks for noting it. (In Zope3 i can tell if i wan't zope to search the HTTP_ 
variant of the variable or not).

The bug affects other variables as well.
In twcgi.py the request.headers.getAllRawHeaders() returns title as mixedcase 
(canonicalNameCaps), while the code for all lowercase.
So it shall be 'Content-Type' and not 'content-type', etc. Shall i file a new 
bug?!

Can you assist me implementing the correct solution?! 
- what should auth object be?!
- where should i attach it?! (In case of  internal auth is some kind of auth onj 
already attached so that it can be readed from twcgi.py)

Miklos.

[mars]

So we need to integrate SCGI authentification with Cred, i.e. attach an Avatar to the SCGI request? It is not obvious what is exactly 'internal authentication' in the discussion above and why we need to send REMOTE_USER/AUTH_TYPE back to web-server. Any explanations/suggestions ?

[jknight]

SCGI itself has no special needs for authentication. SCGI auth will automatically fall out of CGI auth. However, even in CGI, the problem really is getting the authentication information from an authenticator resource to the cgi resource.

I don't really have any particular ideas how this should be done. But it probably shouldn't be special to CGI, but also something which can be used for other resources in the system as well.

[dreid]

Accessing this information is definitately not cred specific. I think it actually falls under #2042. I've written a short proposal to fix the problem up there, and I will hopefully be addressing it in the next week or so.

[dreid]

This could now be used with the web2.auth.wrapper.HTTPAuthResource, which upon successful login adapts request to IAuthenticatedRequest which has an avatar attribute, which may be adaptable to or provide IHTTPUser which has a username attribute.

This would basically be like this i think.

if IAuthenticatedRequest.providedBy(request):
    user = IHTTPUser(request.avatar, None)
    if user:
        environ['REMOTE_USER'] = user.username

This doesn't handle AUTH_TYPE of course, I'm not really sure what AUTH_TYPE should be, I've never seen it used, it looks like it's typically the scheme used during HTTP-Auth but that seems like a pretty useless thing for your code to need to know.

[dreid]

Glyph says he can do this with the stuff in his web2cred-2042 branch. So I'm going to let him.

[glyph]

#2042 has been closed as 'wontfix', so I'm going to close this as well, for the same reason. However, please feel free to file tickets for twisted.web SCGI implementation (and the attendant authentication requirements).