Ticket #1300 (closed task: wontfix)

Opened 5 years ago

Last modified 14 months ago

web2/scgi authentification with REMOTE_USER and Cred

Reported by: boga Owned by: glyph
Priority: high Milestone: Web2-Gold-Master
Component: web2 Keywords: scgi auth
Cc: jknight, dreid, boga Branch:
Author: Launchpad Bug:

Description


Attachments

twisted.diff.txt Download (1.6 KB) - added by boga 5 years ago.
twisted.diff.2.txt Download (1.6 KB) - added by boga 5 years ago.

Change History

Changed 5 years ago by boga

Changed 5 years ago by 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.

Changed 5 years ago by 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.

Changed 5 years ago by boga

Changed 5 years ago by 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.

Changed 4 years ago by mars

  • keywords scgi auth added
  • type changed from defect to task
  • summary changed from web2/cgi hides REMOTE_USER to web2/scgi authentification with REMOTE_USER and Cred
  • component changed from web to web2
  • milestone set to Web2-Gold-Master

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 ?

Changed 4 years ago by 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.

Changed 4 years ago by 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.

Changed 4 years ago by dreid

  • summary changed from web2/scgi authentification with REMOTE_USER and Cred to web2/scgi authentification with REMOTE_USER and Credu

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.

Changed 3 years ago by dreid

  • owner changed from jknight to glyph
  • summary changed from web2/scgi authentification with REMOTE_USER and Credu to web2/scgi authentification with REMOTE_USER and Cred

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

Changed 14 months ago by glyph

  • status changed from new to closed
  • resolution set to wontfix

#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).

Note: See TracTickets for help on using tickets.