Hi Cyril, hi Jamie, On Mon, Feb 20, 2012 at 09:12:56AM -0600, Jamie wrote: > This would be a fantastic feature-add for us as it allows custom > cloud-auth PAM modules too; for example, we can authenticate > against Amazon IAM, Simple DB, Secure Remote Protocol, or anything > else we could imagine using pam_redirector. This might require an > unacceptable combination of dependencies for the build process, but > for us, at least, this would be an incredible feature.
Thanks for advocating the Auth PAM module :-). This is exactly my selling point. While the auth_ldap module is restricted to LDAP, and even then may only cover a subset of LDAP authentication scenarios (since it has to implement each one of them), the auth_pam module should allow anything supported by a PAM module. > On 02/20/2012 01:54 AM, Cyril LAVIER wrote: > >Honestly, I don't think using PAM is a good way to perform a LDAP > >authentication with NGINX, mainly because it requires further > >configuration in other packages than NGINX. Consider it from a different angle: All the nasty implementation details of LDAP authentication are handled outside of nginx, e.g. by libpam-ldap or libpam-ldapd, so you as a maintainer do not have to worry about getting bug reports on memory leaks and such. Before nginx, I was using lighttpd. It contains an LDAP authentication module, which worked well, but unsurprisingly, given the complexity of LDAP, had bugs as well, e.g. “mod_auth leaks ldap connections” [1]. The bug(s) were of course fixed, but this requires active upstream developers as in the case of lighttpd (and nginx itself). [1] http://redmine.lighttpd.net/issues/1066 Further, I would consider the Auth PAM module feature-complete. I would not worry about the configuration too much. There would be no configuration shipped with the nginx-* packages anyway, since there is no default scenario. I would rather include a few examples in the README.Debian or other file. For example, a user comfortable with handling LDAP will be more than capable of configuring a PAM service. This is my configuration right now: # # /etc/nginx/sites-available/example.org # location / { auth_pam example.org; auth_pam_service_name nginx; } # # /etc/pam.d/nginx - LDAP authentication for nginx webserver # auth required pam_ldap.so config=/etc/nginx/pam_ldap.conf account required pam_ldap.so config=/etc/nginx/pam_ldap.conf # # /etc/nginx/pam_ldap.conf # base ou=redmine,dc=example,dc=org uri ldapi:/// ldap_version 3 binddn cn=httpd,dc=example,dc=org bindpw ********************* scope sub pam_password md5 > >Also, did you tried to build/use the module against libpam-ldapd, > >which is used by some people in place of libpam-ldap. I did not test libpam-ldapd yet, but I see no reason why it should not work. The choice of pam_ldap module should not affect the interface between nginx and pam. > >Even if I'm not convinced, I let you a chance to sell me (and > >maybe us, the whole maintaining team) this module, and the > >advantage of using PAM instead of directly connecting to a LDAP > >directory with NGINX. > > > >By the way, adding a module for LDAP authentication is one of the > >tasks on our goals for the Wheezy freeze. We found this module > >(https://github.com/kvspb/nginx-auth-ldap) which directly connects > >to a LDAP directory, and I have been using it over the last > >months, and I didn't had any instabilities with it. It's good to know that nginx-auth-ldap is being tested. I was already aware of the module before, but refrained from using it. I assume that LDAP auth adds a lot more complexity to nginx than the PAM auth. > >Talking about the inclusion of a LDAP auth module in nginx-light > >(and all other flavours), I don't see any issues, as the light > >flavour already has the auth-basic, it's logical to have the > >ldap-auth in it. That was my thought as well, glad you see it this way, as I can keep using the nginx-light package ;-). Regards, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
