[mod_python] req.user and SSL?

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

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 "/"
> > >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

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/ 

More information about the Mod_python mailing list