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 poir...@pobox.com wrote: On 2010-04-30 at 08:38, Jeff Trawick traw...@gmail.com wrote: On Fri, Apr 30, 2010 at 8:12 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com 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: insert please-use-latest-version caveat * 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_attributename [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 kjk...@kevinkal.com 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
Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [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: Seeking suggestions on changes to mod_authnz_ldap [and possibly mod_ldap] supporting X.509/LDAP AA [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 AA 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 AA [AuthType Certificate] On Wed, Apr 21, 2010 at 12:49 PM, Thomas, Peter ptho...@hpti.com 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
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=value of SSL_CLIENT_S_DN_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
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
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
In-progress review: adding AuthType Certificate to integrate Apache web server's mod_ssl mod_authnz_ldap modules
All:
I've been working on integrating mod_ssl and mod_authnz_ldap for
non-password-based environments. I contemplate AuthType Certificate
in https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 . This
enhancement is targeted for environments where the user is authenticated
if they:
1) present a valid SSL client certificate, and
2) a single object corresponding[*1] to that user's certificate exists
at the targeted LDAP server.
To take advantage of the flexibility and utility of the existing module,
I'm extending mod_authnz_ldap instead of writing a separate handler. For
example, once authenticated one can then leverage the Require ldap-*
directives in mod_authnz_ldap. mod_authnz_ldap also populates the
environment with all requested LDAP attributes in AUTHENTICATE_*
environment variables. These can be used in subsequent request
processing [such as fine-grained access control or other logic within
request handlers].
To implement the initial DN matching approach, I had to make a change
to mod_ssl.c to pull out an RFC2253 compliant representation of the
subject DN. My debugging so far suggests this may be causing me
problems--I've included the patch diff at the end of this e-mail for
review and suggestions.
I hope to have a comprehensive prototype patch available shortly for
others that want to test this out. A summary of the changes made to
date follows:
-
Added:
modules/aaa/mod_auth_cert.c
* provider module defining AuthType Certificate based
* registers check user hook authenticate_certificate_user
* TODO: (from [*1], above) matching certificate subject DN to LDAP
object DN is overly restrictive; someday implement a more general
approach which might be based on creating a filter expression to match
DN components, certificate attributes, c.
-
Modified:
Modouls/aaa/mod_auth.h:
* appended check_certificate member to authn_provider struct
modules/aaa/config.m4:
* add APACHE_MODULE(auth_cert, X.509 certificate authentication, , ,
most)
modules/aaa/mod_authnz_ldap.c:
* added authn_ldap_check_certificate, a wrapper for
authn_ldap_check_password after testing for certificate auth
pre-conditions
* changed authn_ldap_check_password to use util_ldap_cache_getuserdn
instead of ..._checkuserid if AuthType is Certificate
* registered authn_ldap_check_certificate as the check_certificate
function for
Modules/ssl/mod_ssl.h:
* TODO: Make the following item configurable, defaulting to original
behavior [ I need RFC2253 format because that is how DNs are stored in
our LDAP server ]
* changed ssl_var_lookup(..., SSL_CLIENT_S_DN) to return
RFC2253-compliant DN instead of using deprecated X509_NAME_oneline
Issues/other TODO items:
* TODO: enhance APR-Util mod_ldap to support two-way SSL and
ldap_sasl_bind_s for environments that support SASL EXTERNAL
authentication based on the LDAP client's certificate; right now
mod_ldap only supports simple binding--anonymous, or with a binddn and
password.
* ssl_var_lookup(..., SSL_CLIENT_S_DN) bails out unexpectedly when
called from mod_auth_cert.c:authenticate_certificate_user
[I know it works elsewhere, because I can get the user name logged in
access_log by using SSLUserName SSL_CLIENT_S_DN]
Here's the diff fragment if anyone wants to take a stab puzzling out
anything I've done wrong:
--- http-2.2.15-baseline/modules/ssl//ssl_engine_vars.c Sat Feb 27
16:00:58 2010
--- http-2.2.15/modules/ssl//ssl_engine_vars.c Tue Mar 23 14:22:53 2010
@@ -367,10 +367,20 @@
}
else if (strcEQ(var, S_DN)) {
xsname = X509_get_subject_name(xs);
-cp = X509_NAME_oneline(xsname, NULL, 0);
-result = apr_pstrdup(p, cp);
-modssl_free(cp);
-resdup = FALSO;
+BIO *bio;
+int n;
+
+if ((bio = BIO_new(BIO_s_mem())) == NULL) {
+result = NULL;
+} else {
+X509_NAME_print_ex(bio, xsname, 0, XN_FLAG_RFC2253);
+n = BIO_pending(bio);
+result = apr_pcalloc(p, n+1);
+n = BIO_read(bio, result, n);
+result[n] = NUL;
+BIO_free(bio);
+resdup = FALSE;
+}
}
else if (strlen(var) 5 strcEQn(var, S_DN_, 5)) {
xsname = X509_get_subject_name(xs)
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
Support for SASL bind in mod_ldap?
Looking at modules/ldap/util_ldap.c , it appears that mod_ldap is hard-wired to support only ldap_simple_bind_s. Has anyone looked into enabling SASL authentication in mod_ldap? Are there any pitfalls I should be cognizant of if I plan to go down that road mysely? --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
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: 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
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 Thomas, Peter L. (ptho...@hpti.com).vcf
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
Time for a new AuthType: cert?
I have been trying for some time to come up with a generalizable solution from the stock mod_authnz_ldap that works in a environment with X.509 certificate-based authentication and LDAP-based authorization. Unfortunately, mod_authnz_ldap was written in such a way that it seems extremely difficult to authorize a user against an LDAP directory if they were not first authenticated against the directory. I've managed to cobble together a solution--only to find that the additional attributes are not queried during authorivation--or if they are, they are not populated into the AUTHENTICATE_* subprocess environment variables. I really want to make as much use of mod_auth_ldap as possible rather than managing my own LDAP connection pool and cache. The hacks that I've had to do to make this work suggest to me that I don't want to overload mod_auth_basic, but what is really appropriate is a new authorization provider--notionally call it cert or cert-ldap. This provider should: 1) for authentication: depend upon mod_ssl configured with an appropriate SSLVerifyClient option. [i.e. decline to authenticate a user if no client cert was passed; be configurable to fail or warn stridently if a client cert was passed but SSLVerifyClient optional_no_ca is in use] 2) for authorization: like mod_authnz_ldap, support dn, group [to include nested group], attribute, and filter require directives 3) provide the same flexibility as mod_authnz_ldap with respect to configuring the LDAP connection and working with various LDAP libraries 4) be configurable to work with users' existing LDAP schemas without requiring changes in the directory. Most of the prior art 3rd party modules I've seen out there seem to fall down in one of more of these respects. I'm new to Apache module development, and I recognize that stepping outside of basic and digest to create an entire new authorization provider type might be a lot to bite off. I invite any suggestions or tips--especially if someone has already cracked this nut in an generalizable way. Thomas, Peter L. (ptho...@hpti.com).vcf
RE: Time for a new AuthType: cert?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] From: Pete Thomas [ptho...@hpti.com] 1) for authentication: depend upon mod_ssl configured with an appropriate SSLVerifyClient option. [i.e. decline to authenticate a user if no client cert was passed; be configurable to fail or warn stridently if a client cert was passed but SSLVerifyClient optional_no_ca is in use] With you here, the big descision is to whether impersonate basic auth or to run before it. I'm leaning against impersonating basic auth. Basic is quick to 401 with note_basic_auth_failure headers if it hasn't received a basic auth header. I don't want that; certificate authentication is a different beast. The nearerst equivalent in the certificate-based paradigm to what Basic does would be to tear down the SSL session and send back a client directive retry the original client request. When entering a password, users make typographical mistakes, and Basic Auth is set up to let them try again. I think for cetrificates this would be a terrible idea--if a client doesn't present a valid certificate the first time, they're not likely to come up with a valid one later. This is why partitioning this into a new authentication type makes sense to me. Done right, we set AuthCertAuthoritative off, and the user can fall back to basic auth. This would behave as it always does without any pollution from the certificate authorization process. 2) for authorization: like mod_authnz_ldap, support dn, group [to include nested group], attribute, and filter require directives disagree here, why/where are you going to query this stuff? Why not just use it in conjunction with LDAP authz? I would love to use LDAP authz. The problem is that as a dual-provider of both authn and authz, there is some tight coupling between phases. So long as mod_authnz_ldap won't weigh in against a user's authentication if the current auth provider isn't Basic, but mod_authz_ldap will work if Requre ldap-* directives exist. My other side finding was that the AUTHENTICATE_* variables get populated during authentication, not authorization. I still need those values if we are using mod_authnz_ldap only for authz. 3) provide the same flexibility as mod_authnz_ldap with respect to configuring the LDAP connection and working with various LDAP libraries -1 if it were going into the actual Apache distribution! Would you be +1 if we could do this by actually USING mod_authnz_ldap [as I contemplate above], with whatever minimally invasive changes [if/as required] to allow a Cert auth provider to use the module [not changing any of its behaviors as a Basic provider]. 4) be configurable to work with users' existing LDAP schemas without requiring changes in the directory. sounds reasonable unless you're drawing a contrast with the current LDAP auth modules. Not drawing a contrast with the core. This is a problem I've had with other 3rd-party, non-distro modules. They point the right direction, but in a couple of cases they didn't have the flexibility to use alternate schemas. For example, mod_authnz_ldap lets you create arrays of group member attribute names to augment or override the default member and uniqueMember. 3rd-party modules often expect a set schema. My goal here is to make something that others can use, not just solve my own problem. In enterprises, you frequently have to live with the directory you're given--you don't get to roll your own. I think AuthType cert is reasonable as long as you can demonstrate using the the traditional authz providers. Agreed. I'll think about what test cases are appropriate to demonstrate functonality without impacting compatibility.
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 samuel.r...@gmail.com 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 cove...@gmail.com: On Sun, Feb 28, 2010 at 5:27 AM, Samuel ROZE samuel.r...@gmail.com 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
[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
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 ptho...@hpti.com 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
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 ptho...@hpti.com 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
