|
Bud P. Bruegger
bud at comune.grosseto.it
Tue Feb 21 05:42:58 EST 2006
At 11.53 20/02/2006 -0500, Deron Meranda wrote: > >>I have a problem reading req.user when using mod-SSL with the > >>+FakeBasicAuth option and setting SSLUser: req.user always seems > >>to be undefined. >... > > I understood that the mod-ssl directive > > >SSLUserName SSL_CLIENT_S_DN_X509 > > tells it to set the subject DN as req.user. Did I understand this > > incorrectly? > > >From the mod_ssl docs: > > "Note that this [SSLUserName] directive has no effect > if the FakeBasic option is used." > >The FaseBasicAuth processing is done early in the UserCheck phase. >Essentially what it does is to synthesize an "Authorization" header as >if the user agent sent it; but otherwise doesn't set anything else. >In this case the username will be the client DN string, and the >password will be "password", and the authorization scheme is "Basic". >Thus it is still up to a later handler, such as auth_basic, to then >re-interpret the authorization header, and set up the req->user field. > Of course this means that the DN and "password" needs to be in one of >it's backend provider databases (httpasswd, LDAP, etc), or it will be >rejected as a bad login. > >[To prevent spoofing, any actual Authorization header sent by the real >user agent is rejected if the password is "password" and the username >starts with a "/". So likewise if that username starts with "/" and >the password was "password", you know it was a synthesized "fake" >login by mod_ssl.] > >The SSLUserName processing on the other hand is done in the middle of >the Access phase. The req->user is set directly to whatever ssl >variable you specify (which internally uses the ssl_var_lookup() >method). Note though that this phase is designed for access control, >not for authentication. So if it gets this far, the client cert has >already been "trusted" as a valid user. There obviously is no >password and auth_basic doesn't get involved. > >Note that mod_ssl is full of informational logging, so you may be able >to see what's going on by capturing the INFO level log output from >apache. Many thanks for clarifying this! Now I understand much better and have to play around to try it out. > > This DN is a string; would there be any requirements for > > accepting a string as user name (e.g., illegal chars)? > >The only restriction I know of is that the user name can not contain a >colon ":" (this restriction comes from the HTTP basic and digest RFC >2617), nor a zero-byte. Note that the DN will always start with a "/" >character. > > > > >Second is that mod_ssl only populates req.user from a MIDDLE hook of the > > >access handler. > > > > Ok, so possibly I don't see it in the access hander, but then I should see > > it in the Fixup stage, shouldn't I? > >Should be correct. Of course you can still get the DN yourself via >ssl_var_lookup() and just ignore the req->user. > > > > Would you recommend to take the trunk instead? > >As Graham said the trunk is probably okay. But if you're just a bit >more cautious, you can grab a stable release (3.2.7 for instance) and >just apply the one set of patches in MODPYTHON-94. > >If you do that though just one head's up.... the patch attached to the >issue uses the method name "ssl_var()", whereas it is integrated on >the trunk (and in future relases) as "ssl_var_lookup()". There's a >couple other tiny differences too...so read all the notes to the #94 >issue and decide for yourself whether you go with the whole trunk or >just this patch. I was actually thinking of doing a back porting of the patch to the version of mod-python I currently run. It looked straight forward enough. I started to read up on how to recompile Debian src packages.. >Also, any feedback (good or bad) is certainly welcome, as this SSL >functionality gets much narowwer testing than other parts of >mod_python. Sure will if I get it to work. Again, many thanks for very useful input! >-- >Deron Meranda ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bud at comune.grosseto.it Comune di Grosseto jabber: bud at jabber.no Via Ginori, 43 http://www.comune.grosseto.it/cie/ 58100 Grosseto (Tuscany, Italy) http://www.comune.grosseto.it/interopEID/
|