Re: Trick PerlAuthzHandler into thinking Basic Auth occurred

[David Castro]

on 08/30/04 13:43 Geoffrey Young wrote: then all you should need to do is set $r->user to the authenticated user and you should be good to go. for completeness, you might also want to set $r->connection->auth_type to 'Basic', but that is most likely not required to get things working. Hrmm. Yeah, this is what I had thought and tried at one point with no luck. When I use basic auth and let mod_authz_ldap do it's thing, I get "...basic LDAP authentication of user 'test'...", but with my auth module (using the code above) I get "...on user '(null)' failed..." in my logs. So, basic auth is doing something that I am not to get that user set for the underlying authz module, I just can't figure out what the heck it is. well, I can't find either of those error messages in mod_auth_ldap from http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html Ooops, yeah.  A follow-up email corrected "mod_authz_ldap" to "mod_auth_ldap".  Sorry 'bout that.  To give a bit more detail, I am using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0.  Went looking through the C code of the authz module and found the function it gets the credentials from: char    *authz_ldap_get_userdn(request_rec *r) {     authz_ldap_config_rec   *sec;     sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);     return sec->userdn; } Here is the debugging lines for mod_authz_ldap from my apache logs: [Mon Aug 30 14:21:07 2004] [debug] authz.c(412): [client 10.10.105.236] [11032] authz_ldap_authz called by user '(null)' for URI '/test/' [Mon Aug 30 14:21:07 2004] [debug] utilities.c(38): [client 10.10.105.236] [11032] initialize LDAP connection [Mon Aug 30 14:21:07 2004] [debug] utilities.c(60): [client 10.10.105.236] [11032] got ldap connection to *************:389 at 0x08dc05d8 [Mon Aug 30 14:21:07 2004] [debug] utilities.c(74): [client 10.10.105.236] [11032] protocol version set to 3 [Mon Aug 30 14:21:07 2004] [debug] utilities.c(135): [client 10.10.105.236] [11032] bind to ldap server succeeded [Mon Aug 30 14:21:07 2004] [debug] authz.c(423): [client 10.10.105.236] [11032] LDAP connection established [Mon Aug 30 14:21:07 2004] [debug] authz.c(446): [client 10.10.105.236] [11032] starting with return code 0 [Mon Aug 30 14:21:07 2004] [debug] authz.c(460): [client 10.10.105.236] [11032] processing requirement role 507 [Mon Aug 30 14:21:07 2004] [debug] authz.c(513): [client 10.10.105.236] [11032] role(s) required: 507 [Mon Aug 30 14:21:07 2004] [debug] authz.c(199): [client 10.10.105.236] [11032] allocating 20 bytes for role filter [Mon Aug 30 14:21:07 2004] [debug] authz.c(204): [client 10.10.105.236] [11032] role filter: (gidNumber=507) [Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(50): [client 10.10.105.236] performing substitutions in filter '(gidNumber=507)' [Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(102): [client 10.10.105.236] filter substitutions give new filter '(gidNumber=507)' [Mon Aug 30 14:21:07 2004] [debug] authz.c(47): [client 10.10.105.236] [11032] checking filter '(null)' for user '(gidNumber=507)' [Mon Aug 30 14:21:07 2004] [debug] utilities.c(174): [client 10.10.105.236] [11032] search from '(null)' for '(gidNumber=507)' returns 32 [Mon Aug 30 14:21:07 2004] [debug] utilities.c(191): [client 10.10.105.236] [11032] retry the search [Mon Aug 30 14:21:07 2004] [error] [client 10.10.105.236] ldap [11032] search for filter '(gidNumber=507)', scope = 0 on user '(null)' failed [Mon Aug 30 14:21:07 2004] [debug] authz.c(209): [client 10.10.105.236] [11032] role requirement failed [Mon Aug 30 14:21:07 2004] [debug] authz.c(585): [client 10.10.105.236] authz_ldap_authz()[11032]: elapsed time: 37ms, cpu time: 0ms [Mon Aug 30 14:21:07 2004] [debug] authz.c(587): [client 10.10.105.236] [11032] return code from authz_ldap_authz: NOK (403) on in httpd-2.0, so I'm not sure exactly where the error is coming from. one thing of interest is that in the former code they call ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will subvert the approach I outlined above. but if you can't set the Authorization header either (recipe 13.4) and have it work then I don't know. anyway, if you give me a pointer to the mod_auth_ldap code you're using I can look it over and see, but there are only a few different places where the user information can come from - $r->user directly, or from the Authorization header. well, I guess there is a third - mod_auth_ldap could assume (or require) that it is the authentication handler and instead of looking in those two places it could rely on some internal cache. in fact, this seems to be the case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly for this purpose. the docs indicate that you should set it to "no" if you want to use something other than mod_auth_ldap for the authentication phase, which is what you are trying to do. so, have you set this directive and tried a the other two approaches (setting the incoming header and/or just $r->user)? --Geoff -- David Castro Software Architect Azusa Pacific University "My little children, let us not love in word or in tongue, but in deed and in truth." -- 1 Jn 3:18 (NKJ)