RE: mod_ssl, SNI and dynamic virtual hosts
Loading & processing server certificates, keys, trust chains, and CRLs Request time doesn't make sense to me, unless it's implemented as a "one-time cost" for the first use of a dynamic virtual host. Are these virtual hosts truly dynamic? It seems that there would have to be some a priori knowledge of the possible servers you might be hosting. Are you in fact proposing some mechanism whereby you provide a path generator as in "certs/%s/server.crt" where Apache will look for the certificates [and other files] defining the PKI environment for each dynamic virtual host, and that further these files might not have been present on the system at httpd's startup? Warmly, --Pete > -Original Message- > From: Adam Hasselbalch Hansen [mailto:a...@one.com] > Sent: Tuesday, May 25, 2010 7:06 AM > To: dev@httpd.apache.org > Subject: Re: mod_ssl, SNI and dynamic virtual hosts > So what I'm attempting to get feedback on is whether or not > it will be possible or even feasible to move certificate > loading (as in the actual reading of certificate files) from > startup time to request time, and if so, what caveats if any > this may lead to.
Re: Stop accepting PRs for 1.3?
How about putting out a call for volunteer community maintainers and let them take over the project. Make it clear on the home page and bug submission pages & e-mails that ASF is leaving Bugzilla and other fora as a courtesy to the 1.3 user community. Any concerns should be sent to the volunteer maintainers. Hopefully there will be several volunteers. If nobody is willing to step up and do the work, I think that answers the question. If there are no takers, change the workflow such that new PRs are "noted" and change the assignment email address to "|/dev/null". Dan Poirier wrote: On 2010-04-30 at 08:38, Jeff Trawick wrote: > On Fri, Apr 30, 2010 at 8:12 AM, "Plüm, Rüdiger, VF-Group" > wrote: >> >> +0.5 >> >> I am a little bit undecided as it might be still a useful forum for >> users to share bugs and patches for them with other users alltough >> the won't get fixed / applied by us anymore. > > same general concern here: some community will still use httpd 1.3, > and IMO we don't want to further separate them from the modern-httpd > crowd > > Whether or not the bug db is closed to 1.3, we should doc on the front > page what we provide in support of the 1.3 community: > > > > * 1.3 discussions welcome on user mailing list > * users welcome to share 1.3 howtos/workarounds on the Httpd Wiki > (subject to general policies of the wiki) > * security reports on 1.3 accepted and analyzed on > secur...@apache.org; any resulting approved patches maintained in > patches/apply_to_1.3... directory > * possibly: users share problem reports/patches in the bug db My concern is that people will submit 1.3 bug reports, and get frustrated when there's no "official" response. Is there a way we can keep 1.3 submissions open but make the level of support for 1.3 clear to bug submitters? Dan
RE: patch for mod_ldap_authnz
This is an alternate path that I considered in my AuthType Cert work. I didn't choose it, because it was actually meaningful in my situation to declare a user with an otherwise valid certificate "unauthenticated" if no matching LDAP record could be found. I agree with Eric that "AUTHENTICATE_" isn't the best prefix [of course, we need to respect the installed base that may be depending upon it]. I think a more appropriate prefix might be "LDAP_" [semantically I think this is a better way to "hint" that the value for the attribute came from an LDAP search]. > -Original Message- > From: Eric Covener [mailto:cove...@gmail.com] > Sent: Tuesday, April 27, 2010 10:37 PM > To: dev@httpd.apache.org > Subject: Re: patch for mod_ldap_authnz > > On Tue, Apr 27, 2010 at 9:25 PM, Kevin Kalupson > wrote: > > Hi, > > mod_authnz_ldap will put the attributes from the > AuthLdapUrl in the > > request environmental variables if ldap is the > authentication source. > > However, if mod_authnz_ldap is only providing Authorization and > > another module is the authentication source, the attributes are not > > available as request variables. > > > > Anyone have feelings about LDAP-as-authorizer adding entries > to AUTHENTICATE_*? Seems like an unfortunate name given the > nature of the data people are likely to plug into with this. > > Perhaps hide it behind a directive in mod_authnz_ldap and let > users pick the prefix during authz? > > -- > Eric Covener > cove...@gmail.com >
RE: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP A&A [AuthType Certificate]
It's mandatory IFF: 1) The certificate subject is the LDAP DN, AND 2) There isn't an LDAP object attribute that can be uniquely mapped to a specific certificate subject DN component When it isn't mandatory--but the certificate subject is the LDAP object's DN--then an LDAP_SCOPE_BASE search improves performance for LDAP servers--and thus for relying Apache servers. I can't speak to importance--it's important to me, or I would have dropped it by now instead of pressing forward. I keep running in to people who have solved this or similar problems at the application (or application server layer) [in PHP, RAILS, J2EE, Joomla, &c.] It's always seemed like this cries out for handling right where we do SSL termination & initial AAA--in httpd. This is never going to be something that the whole world wants; this capability applies only to situations where X.509 certificates are distributed to users AND LDAP is used to make A&A decisions based upon users' certificates presented to web servers. --Pete -- > -Original Message- > From: Eric Covener [mailto:cove...@gmail.com] > Sent: Wednesday, April 21, 2010 1:39 PM > To: modules-...@httpd.apache.org > Subject: Re: Seeking suggestions on changes to > mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP > A&A [AuthType Certificate] > > On Wed, Apr 21, 2010 at 12:49 PM, Thomas, Peter > wrote: > > When the user's certificate subject is also the DN of the > LDAP object, > > one can optimize search and compare operations by doing a > > LDAP_SCOPE_BASE search for the object based on the subject > DN. I was > > able to substitute a search for the exact LDAP object in the > > authentication code. For authorization, I ran into a problem. The > > LDAP search cache entries for a URL are unique by filter > expression. > > If ANY user was cached for a specific ldap-filter, the search cache > > has no way of knowing that I'm applying that search to a different > > search base. I could create a separate cache for every user > > encountered [i.e. by changing the base component of the LDAP URL > > before calling any > > uldap_cache_* function]. That seems painful. Thoughts? > > > > How important is this optimization to either Apache or the > LDAP server? > > -- > Eric Covener > cove...@gmail.com >
Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP A&A [AuthType Certificate]
When the user's certificate subject is also the DN of the LDAP object, one can optimize search and compare operations by doing a LDAP_SCOPE_BASE search for the object based on the subject DN. I was able to substitute a search for the exact LDAP object in the authentication code. For authorization, I ran into a problem. The LDAP search cache entries for a URL are unique by filter expression. If ANY user was cached for a specific ldap-filter, the search cache has no way of knowing that I'm applying that search to a different search base. I could create a separate cache for every user encountered [i.e. by changing the base component of the LDAP URL before calling any uldap_cache_* function]. That seems painful. Thoughts?
RE: Improved AuthType Certificate provider [enhancement #48780]
> [...] There's an old thread on this same > subject, and a module, that you can find at > https://sourceforge.net/projects/modauthcertific/ That's one of the prior examples I looked at in coming up with this approach. IIRC, it depended on a rigidly defined LDAP schema. Dictating the schema is often not an option for existing environments. > I would suggest collecting the design decisions, and the > interactions with authn/authz/access control in trunk > somewhere so people can follow without too much investment. > Include config examples/use cases. Will do. I definitely haven't addressed documentation of any of this yet. Is there a template or pattern for config examples and use cases? A pointer to one or more "well-done" use cases would suffice. > The contentious parts for these things are usually: > How does the cert map to r->user? I stayed with the spirit of mod_ssl here. By default r->user becomes the certificate subject DN ( SSL_CLIENT_S_DN ). If the SSLUserName directive is employed, use that instead. The advantage of this approach is that it should work with almost every LDAP implementation--those where the certificate subject is also the LDAP object's DN, and those where a component of the subject--such as the CN--must be matched to an attribute of the LDAP object. As I noted in the bugzilla entry, though, I had to "tweak" mod_ssl to return the DN in RFC2253 format. The backwards compatible thing to do is to configure mod_ssl to optionally return the DN in RFC2253 syntax OR add a new SSL variable that has the LDAP-formatted DN, and then use SSLUserName to select that variable when needed. [The current behavior in mod_ssl used to retrieve the subject or issuer DN uses a method formally deprecated in OpenSSL--of course, it's not likely that it'll be going away any time soon.] Examples: 1) # Find the user's entry in LDAP by matching a component of the subject certificate to an attribute in LDAP SSLUserName SSL_CLIENT_S_DN_UID AuthLLDAPUrl ldaps://ldap.example.com/dc=example,dc=com?uid,fullname?sub # For AuthType Certificate, mod_authnz_ldap will do a subtree search # from dc=example,dc=com for (&(uid=)(objectclass=*)) 2) # Find the user's entry in LDAP by the full certificate subject DN AuthLDAPUrl ldaps://ldap.example.com/dc=example,dc=com?fullname?sub AuthLDAPRemoteUserIsDN # Currently, I'm overloading the semantics of AuthLDAPRemoteUserIsDN: # when AuthType is Certificate this directive causes us to do an # LDAP_SCOPE_BASE search for r->user, expected to be the full DN in RFC2253 # this is guaranteed to return either 0 or 1 directory objects. # In this scenario fullname is still retrieved and placed in the AUTHENTICATE_FULLNAME # environment variable; it is not used to search for the LDAP object. Likewise the # scope parameter of the LDAP URL is ignored for authentication. > How does one express that basic-auth-if-no-certificate > (AuthType foo bar, or does the cert module pre-empty basic > auth via some other config mechanism) What if anything > changes in authorization providers (hopefully nothing) In effect, nothing changes in the auhorization providers. "AuthType Certificate Basic" does exactly what you would hope, for example: AuthType Certificate Basic AuthName "Certificate authentication with Basic fallback" AuthCertificateProvider ldap AuthBasicProvider file # Allow fallback from mod_authnz_ldap if user is not found in LDAP; compare to AuthBasicAuthoritative AuthCertificateAuthoritative off I say "in effect," because to simplify implementation, I reused the existing method. For Basic auth, there's no logical change. For Certificate auth, I update behavior as appropriate. > Unfortunately, doing this right in trunk probably makes it > unbackportable. Getting it by hook or by crook in a I have a working 2.2 implementation; I guess I'm signing up to distinct changes per-branch, rather than a trunk commit and a 2.2 backport. I'm hoping that's not as bad as one might think at first blush--where I've made changes to the single authorization method in 2.2, I'd just have to distribute those changes appropriately to each distinct Require ldap-* directive method in the trunk. > standalone 2.2 module might mean making it look like basic > auth internally and would probably not be suitable for the > base distribution. I'm not sure what you mean; I definitely want to avoid doing anything unsuitable. What do I need to guard against?
Improved AuthType Certificate provider [enhancement #48780]
As promised in my note last week, I've created an updated patch attached to my suggested feature in https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 . This patch works in my integration environment, tested with all Require ldap-* directives. Notes: 1) When using certificates we can often expect that the DN of the user matches the subject DN of the certificate. For that reason I made a slight overloading of AuthLDAPRemoteUserIsDN. This new behavior is only active in the proposed patch if AuthType is Certificate and AuthLDAPRemoteUserIsDN is on. In those circumstances, LDAP authn will do an LDAP_SCOPE_BASE search for the user at the DN specified in the certificate. I updated the corresponding authz methods to make sure that we are always searching for the user's DN in a consistent way. When the special circumstances do not apply, you continue using the first attribute in the LDAP URL's attribute list compared with the username to find the user [the legacy behavior]. 2) I updated ssl_engine_vars.c in mod_ssl. The current SSL_CLIENT_S_DN uses X509_NAME_oneline(xsname, NULL, 0) which is a) deprecated and b) not in an LDAP-friendly (RFC2253-compliant) form. I updated the code to use X509_NAME_print_ex(bio, xsname, 0, XN_FLAG_RFC2253). Since the vast majority of the use of SSL_CLIENT_S_DN is cosmetic [logging, etc.] I don't foresee this causing a substantial problem. That said, if someone wants to take a stab at making this configurable before we move forward, I'm amenable. 3) The only added directives in all this are: AuthCertificateProvider and AuthCertificateAuthoritative They behave exactly as their counterparts from mod_auth_basic...So far only mod_authnz_ldap is supported [by this patch], as in: AuthType Certificate AuthName "SSL Certificate-Based Authentication" AuthCertificateProvider ldap [...followed by AuthLDAP settings, &c.] I have not sought out commt privileges on the project. I'm not sure this is the sort of feature we should be adding directly to 2.2.x, even if I was able to. What I would like is for other people with interest in the problem space to try this patch out in their own environments and get back to me and the community and with suggestions and observations. --Pete
AuthType Certificate integration completed; patch forthcoming
All: I just completed an end-to-end test demonstrating authentication and simple ["Require valid-user"] authorization mapping an X.509 certificate to an LDAP entry using my new "mod_auth_cert" module. The module implements "AuthType Certificate." I believe the Require ldap-* directives will work as well. (I didn't have to make any changes in the authorization side of mod_authnz_ldap.c.) By extending mod_authnz_ldap, I've avoided the limitations of various 3rd party solutions such as dependence upon specific LDAP schemas. The only requirement my solution imposes is that an attribute in the user's LDAP entry must match the subject of their SSL client certificate. In support of that requirement--at least as implemented in my environment--I'm also adding a new optional flag to mod_ssl that will render the certificate subject in RFC 2253 [XN_FLAGS_RFC2253] format. (By default the current [reversed DN, slash-delimited] rendering of the certificate subject will be used.) I have to go through some machinations to move the patch from my integration test environment out to the Internet for posting to bugzilla. Once I do, I'll at least take a stab at adding documentation and update my existing feature request with the final proposed patch. --Pete
Adding a new module to the build
I added my new proposed module to modules/aaaconfig.m4, but that only got the module build--not installed--even when --enable-auth-cert is included in my configure options. I need to re-run buildconf, and I'm getting a bunch of warnings such as: autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' [...] is deprecated and discuraged [...] autoheader: WARNING: Using the third argument of `AC_DEFINE' and [...] `AC_DEFINE_UNQUOTED' allows one to define a template without [...] `acconfig.h': [...] configure.in.57: warning: LTOPTIONS_VERSION is m4_required'd but not m4_defun'd aclocal.m4:69: LT_INIT is expanded from... aclocal.m4:104: AC_PROG_LIBTOOL is expanded from... Configure.in:57 the top level I also get similar warnings for LTSUGAR_VERSION, LTVERSION_VERSION, LTOBSOLETE_VERSION, LT_OPTIONS_VERSION There are four errors, all "possibly undefined macro" for the following: AC_LIBTOOL_WIN32_DLL, m4_ifval, _LT_SET_OPTIONS, and LT_INIT Platform information: Solaris 10 (sparc) python version 2.4.4, autoconf version 2.63, libtool version 2.2.6b Any idea what [if anything] is causing this? How do I fix it? --Pete
RE: Fighting with build process 2.2.x on Sparc Solaris 10
> -Original Message- > From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] > Sent: Friday, March 05, 2010 5:59 PM > To: dev@httpd.apache.org > Subject: Re: Fighting with build process 2.2.x on Sparc Solaris 10 > What if -lm is placed after libapr[util]? Not sure what is > going on, but it looks like you might be building some of > this with sun cc and part with gnu cc (gcc)? After much wrangling, I was able to build using cc from SUNWspro [sun cc/sun developer studio cc?] and the Coolstack source package. Coolstack bundles up nearly all of the runtime dependencies, solving whatever mixing I had done trying to build from the "ground up." +1 for Coolstack! --Pete
RE: DSO question
> -Original Message- > From: Ben Noordhuis [mailto:i...@bnoordhuis.nl] > Sent: Tuesday, March 09, 2010 1:34 PM > To: modules-...@httpd.apache.org > Subject: Re: DSO question > > > What I need is to tell to APR, hey APR please find the > function "f10" > > in all loaded libraries, then execute the function and give > me back the result. Thankfully APR defines handy macros for such a purpose... Look at the macros: APR_DECLARE_OPTIONAL_FN APR_REGISTER_OPTIONAL_FN APR_OPTIONAL_FN_TYPE APR_RETRIEVE_OPTIONAL_FN As the other poster pointed out, there is no magic bullet for knowing where the function is declared! You will have to include the relevant header where the APR_DECLARE_OPTIONAL_FN appears. So, if you want to use ssl_var_lookup from mod_ssl.h you will still have to #include "mod_ssl.h" in your module. If you look at ./srclib/apr-util/include/apr_optional.h and ./srclib/apr-util/hooks/apr_hooks.c, you can see under the hood that the implementation is much like the other respondent suggested, except that an apr_hash is used to register and look up functions, instead of an array. See, for example, this line from apr_hooks.c: [...] return (void(*)(void))apr_hash_get(s_phOptionalFunctions,szName,strlen(szName)) ; [...] --Pete
RE: Fighting with build process 2.2.x on Sparc Solaris 10
Getting further [in addition to pulling down the obvious additional dependency, libnet]: 1) check out the last released version of apr and apr-util [v1.3.9] 2) configure, build, and install apr 3) configure, build, and install apr-util [ran into a subtle problem where installing apr-util writes back into the local build directory, which was denied because my home directory was root_squashed--rebuilt apr-util under /var/tmp/apr-util, installed from there, and then moved it back into my srclib tree]. 4) configure & build httpd Now I'm getting an odd-ball error while building httpd...thoughts? /bin/cc -L/usr/local/lib -I/usr/local/include -L/usw/sfw/lib -I/usr/sfw/include -xO4 -xchip=generic -I/usr/sfw/include/openssl -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -L/usr/local/lib -I/usr/local/include -L/usw/sfw/lib -I/usr/sfw/include -I/usr/sfw/include/openssl -I/.../httpd-2.2.x/srclib/pcre -I. -I/.../httpd-2.2.x/os/unix -I/.../httpd-2.2.x/server/mpm/prefork -I/.../httpd-2.2.x/modules/http -I/.../httpd-2.2.x/modules/filters -I/.../httpd-2.2.x/modules/proxy -I/.../httpd-2.2.x/include -I/.../httpd-2.2.x/modules/generators -I/.../httpd-2.2.x/modules/mappers -I/.../httpd-2.2.x/modules/database -I/usr/local/apr/include/apr-1 -I/.../httpd-2.2.x/modules/proxy/../generators -I/usr/sfw/include -I/.../httpd-2.2.x/modules/ssl -I/.../httpd-2.2.x/modules/dav/main -c /.../httpd-2.2.x/server/buildmark.c /usr/local/apr/build-1/libtool --silent --mode=link /bin/cc -L/usr/local/lib -I/usr/local/include -L/usw/sfw/lib -I/usr/sfw/include -xO4 -xchip=generic -I/usr/sfw/include/openssl -L/usr/sfw/lib -o httpd modules.lo buildmark.o -export-dynamic server/libmain.la modules/aaa/libmod_authn_file.la modules/aaa/libmod_authn_default.la modules/aaa/libmod_authz_host.la modules/aaa/libmod_authz_groupfile.la modules/aaa/libmod_authz_user.la modules/aaa/libmod_authnz_ldap.la modules/aaa/libmod_authz_default.la modules/aaa/libmod_auth_basic.la modules/filters/libmod_include.la modules/filters/libmod_filter.la modules/loggers/libmod_log_config.la modules/metadata/libmod_env.la modules/metadata/libmod_setenvif.la modules/metadata/libmod_version.la modules/ssl/libmod_ssl.la modules/http/libmod_http.la modules/http/libmod_mime.la modules/generators/libmod_status.la modules/generators/libmod_autoindex.la modules/generators/libmod_asis.la modules/generators/libmod_cgi.la modules/mappers/libmod_negotiation.la modules/mappers/libmod_dir.la modules/mappers/libmod_actions.la modules/mappers/libmod_userdir.la modules/mappers/libmod_alias.la modules/mappers/libmod_so.la server/mpm/prefork/libprefork.la os/unix/libos.la -lm /.../httpd-2.2.x/srclib/pcre/libpcre.la /usr/local/apr/lib/libaprutil-1.la -lexpat -liconv /usr/local/apr/lib/libapr-1.la -luuid -lsendfile -lrt -lsocket -lnsl -lpthread Undefined first referenced symbol in file __divdi3server/.libs/libmain.a(util_time.o) (symbol belongs to implicit dependency /usr/local/lib/libgcc_s.so.1) __moddi3server/.libs/libmain.a(util_time.o) (symbol belongs to implicit dependency /usr/local/lib/libgcc_s.so.1) __ashldi3 server/.libs/libmain.a(core.o) (symbol belongs to implicit dependency /usr/local/lib/libgcc_s.so.1) __ashrdi3 server/.libs/libmain.a(core.o) (symbol belongs to implicit dependency /usr/local/lib/libgcc_s.so.1) ld: fatal: Symbol referencing errors. No output written to httpd *** Error code 1 make: Fatal error: Command failed for target `httpd' Current working directory /.../httpd-2.2.x *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' srclib os server modules support'; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z 'httpd '; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi
Fighting with build process 2.2.x on Sparc Solaris 10
In order to test my certificate authentication provider code, I need to be able to build with LDAP & SSL support. I've tried pulling .../branches/2.2.x and .../tags/2.2.14 and working from buildconf up to a working Makefile to no avail. I've installed every dependency I can find, added every appropriate lib directory to LD_LIBRARY_PATH, and added -I directives to the include files to CFLAGS and CPPFLAGS. Nothing I do seems to work. My problems started when the buildconf file tells me that I have to check out .../apr/apr-util/trunk--and that no longer exists! I think I've managed to get apr built, but I am dying in apr-util. $ uname -a SunOS app1-t2-dev 5.10 Generic_127111-09 sun4v sparc SUNW,Sun-Fire-T200 $ pkginfo | grep SMC application SMCapr apr application SMCaprutil aprutil application SMCautoc autoconf application SMCexpat expat application SMClgcc346 libgcc application SMClibt libtool application SMCliconvlibiconv application SMClintl libintl application SMCm4m4 application SMCncurs ncurses application SMColdap openldap application SMCossl openssl application SMCsasl sasl application SMCsed sed /bin/bash /.../httpd-2.2.x/srclib/apr/libtool --silent --mode=link /bin/cc-L/usr/local/lib -I/usr/local/include -L/usw/sfw/lib -I/usr/sfw/include -xO4 -xchip=generic -release 1 -module -rpath /usr/local/apr/lib/apr-util-1 -o ldap/apr_ldap.la ldap/apr_ldap_init.lo ldap/apr_ldap_option.lo ldap/apr_ldap_rebind.lo -lldap -llber -llber ld: fatal: library -lnet: not found ld: fatal: File processing errors. No output written to ldap/.libs/apr_ldap-1.so *** Error code 1 make: Fatal error: Command failed for target `ldap/apr_ldap.la' Current working directory /.../httpd-2.2.x/srclib/apr-util *** Error code 1 The following command caused the error: otarget=`echo all-recursive | sed s/-recursive//`; \ list='xml dbd dbm encoding hooks buckets misc crypto uri strmatch memcache dbm/sdbm ldap xlate '; \ for i in $list; do \ if test -f "$i/Makefile"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z "libaprutil-1.la aprutil.exp apu-config.out dbd/apr_dbd_pgsql.la ldap/apr_ldap.la"; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' Thoughts?
RE: X.509 certificate against LDAP authentication
I found ssl_list_ext(...) -- used, for example, in mod_setenvif.c -- which looked really promising for generalized access to the client certificate elements without depending on whether mod_ssl.c configuration options as +StdEnvVars or SSLUserName had been set. I'm still wrangling with how to handle the mapping of the certificate subject into an LDAP query in a generalizable way. RFC-2252 and RFC-2253 offer some tantalizing hints...as well as the caveat that there is not a deterministic reversal from an X.500 subject to an LDAP DN. We knew that already, right? --Pete > _ > From: Thomas, Peter > Sent: Wednesday, March 03, 2010 4:20 PM > To: 'modules-...@httpd.apache.org' > Subject: X.509 certificate against LDAP authentication > > Looking at some of the prior work in this area. It appears that one of > the big challenges in cert-based authentication is in the mapping > between the certificate subject and the directory entry. > > If I'm creating something for general consumption, I want to make it > generalizable to multiple environments. In looking at the other > people that have implemented this with hooks and "shim modules," I've > seen several different techniques for certificate mapping & > authentication. I'd like my proposed enhancement to be as widely > usable as possible. Looking at the code, I think the greatest > opportunity for reuse of existing code and consistency with the > architecture lies in creating support for the certificate > authentication type within the current modules, starting with > mod_authnz_ldap. > > With respect to mapping & authentication, the approaches I'm > considering are to allow one or more of the following: > > 1) Authenticate a user by the full binary certificate, assuming that > each user will have one or more valid certificates stored in the > directory in an attribute such as "usercertificate;binary" > 2) Authenticate a user by mapping the certificate subject to a DN > [How?] > 3) Authenticate a user by some combination of elements such as > subject CN and issuer CN against a directory of certificates? > > I saw one case in my research where only groups existed in LDAP--no > users entries.To address that, it occurs to me that there might also > be an "option 0": > > 0) Authenticate a user by the presence of an accepted certificate, > without reference to a specific entry in the directory--i.e. any valid > certificate that comes out of mod_ssl is treated as an authenticated > user.] This would let one authorize a user based on membership in a > group when only groups are populated. > > Looking at mod_auth_basic and mod_auth_digest, it looks like I need to > come up with a user name fairly early on. I intend to hook the > handler with mod_ssl.c as a predecessor. Any thoughts on the most > appropriate way to pull the peer certificate out of the connection and > then map it to a user name? I'm trying to avoid using SSLUserName > from mod_ssl, because we might need the certificate--but I don't want > to set the username to be the client certificate. That makes for > unfriendly reading in logs. Rather, I want to have some mapping [such > as in "option 2" above] from the certificate to the user name. > > In my ideal world, I would meet this goal with an absolute minimal > change to the code-base: > > 1) add a new file "modules/aaa/mod_auth_cert.c" to support "AuthType > certificate" > 2) add a "check_certificate" method to mod_authnz_ldap.c that maps > from a certificate to a user search and "succeeds" if the criteria for > existence of a user is met > 3) Reconcile any explicit or implicit assumptions that we are using > AuthType basic. > > I appreciate any thoughts and pointers. > > --Pete > > --- > Peter L. Thomas, ptho...@hpti.com > (w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910 > << File: Thomas, Peter L. (ptho...@hpti.com).vcf >>
Re: After-request hooks or asychronous modules
The trick with any such thing is in protecting yourself from attack. Consider...you could fork, let the parent continue on its business, disown the child, and do your work there. Easy in terms of lines of code, but expensive (forks) and potentially hazardous. You could create a thread pool to do the job, and only block the response when you had to wait for a worker. More complex to code, but you control how much of your resources you're willing to expend. Samuel ROZE wrote: A dedicated process or thread just for my module, or still linked to the Apache request? The better thing is to create a thread unlinked with the Apache request, it is possible? I'm like a Newbie with Apache module development, is there somewhere an example or a sample of code? Like I said, the better thing is that I create a thread (more efficient than process I thing) which could run 10s if it want without interfering with the initial request and with others. I thing it isn't easy, that's why I need a few help :-) Thanks a lot for your reply, Samuel. 2010/2/28 Eric Covener : > On Sun, Feb 28, 2010 at 5:27 AM, Samuel ROZE wrote: >> Yes, the log_transaction hook is what I expect, thanks! :-) >> >> But I've still a problem: if in my hook function I put a sleep function, >> which sleep for 10 seconds for example, the first page is served >> correctly (few ms) but for the next, it will wait for these 10s (not >> really 10s but the rest time), is it because I should have threads? > > You could start a dedicated thread or process in e.g. post_config and > just post work to it asynchronously in log_transaction. > > > -- > Eric Covener > cove...@gmail.com >
RE: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
Yes, I believe this patch would do that so long as the user name passed by the other authentication provider in conjunction with the options to the LDAP provider brings back one-and-only-one result for valid users. Maybe we don't need to make all those checks and references against mod_ssl I discussed, but rather create a new authentication provider, e.g. "mod_authn_ssl" that does more than just pass a user name and password as mod_ssl's +FakeBasicAuth does, but actually fully authenticates the user, without authorizing them. Is this what you were getting at in your original comment? Even if we do this, we * still * need this patch or something like it to tell the LDAP provider that it should only perform authorization, and not authentication. [Effectively we would be telling it to start with the compare phase, and do so WITHOUT binding as the user.] --Pete -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Monday, February 22, 2010 12:23 PM To: dev@httpd.apache.org Subject: Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780 On Mon, Feb 22, 2010 at 12:15 PM, Thomas, Peter wrote: > The beauty is that it doesn't change the authorization behavior, except to > the extent that the bind-as-user is bypassed if the option is set. I only > found one location that attempted to validate the user's password, so I > surmized that was the 2nd [compare] operation, and I used the "get user DN" > variant which--according to the mod_ldap documentation, verified by my visual > inspection--is a copy of "check user cert" without the user bind. > But wouldn't that mean LDAP authorization + any other authentication provider would be working today? -- Eric Covener cove...@gmail.com
RE: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
The beauty is that it doesn't change the authorization behavior, except to the extent that the bind-as-user is bypassed if the option is set. I only found one location that attempted to validate the user's password, so I surmized that was the 2nd [compare] operation, and I used the "get user DN" variant which--according to the mod_ldap documentation, verified by my visual inspection--is a copy of "check user cert" without the user bind. --Pete -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Monday, February 22, 2010 12:08 PM To: dev@httpd.apache.org Subject: Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780 On Mon, Feb 22, 2010 at 11:46 AM, Thomas, Peter wrote: > [ c.f. https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 ] > > Eric Covener has commented, and I replied, to my suggested enhancement > for mod_auth_ldap. In this case, I am attempting to use LDAP for > authorization, accepting authentication from another provider--this > would most typically be mod_ssl, but I've seen other "in-family" cases > in Bugzilla's history where people are working to integrate SSO with > other authentication providers such as Kerberos [or more generally > GSSAPI]. > > The as-is implementation re-binds the LDAP connection using the user > and password provided to perform the compare phase. The proposed > patch adds a [non-default] option to the LDAP provider that causes the > compare phase to occur without a user-specific re-binding. I haven't dug too deeply, but I didn't see how the attached patch changed the authorization-time behavior. Can you elaborate? -- Eric Covener cove...@gmail.com
[PATCH 48780] Input and improvements requested for suggested enhancement 48780
[ c.f. https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 ] Eric Covener has commented, and I replied, to my suggested enhancement for mod_auth_ldap. In this case, I am attempting to use LDAP for authorization, accepting authentication from another provider--this would most typically be mod_ssl, but I've seen other "in-family" cases in Bugzilla's history where people are working to integrate SSO with other authentication providers such as Kerberos [or more generally GSSAPI]. The as-is implementation re-binds the LDAP connection using the user and password provided to perform the compare phase. The proposed patch adds a [non-default] option to the LDAP provider that causes the compare phase to occur without a user-specific re-binding. In the comments, I contemplate various "sanity checks" to prevent--or at the very least strongly caution against--inappropriate, insecure uses of this option. --Pete
