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?
Re: Improved AuthType Certificate provider [enhancement #48780]
On Tue, Apr 6, 2010 at 7:51 PM, Thomas, Peter wrote: >I 'm not sure this is > the sort of feature we should be adding directly to 2.2.x, Seems like a stretch. There's an old thread on this same subject, and a module, that you can find at https://sourceforge.net/projects/modauthcertific/ 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. The contentious parts for these things are usually: How does the cert map to r->user? 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) Unfortunately, doing this right in trunk probably makes it unbackportable. Getting it by hook or by crook in a standalone 2.2 module might mean making it look like basic auth internally and would probably not be suitable for the base distribution. -- Eric Covener cove...@gmail.com
Re: docs-build as an svn external?
On 4/9/2010 3:21 PM, André Malo wrote: > * Rich Bowen wrote: > > >> Is there any particular reason *not* to have docs-build as an svn >> external under the docs/manual directory? >> >> (It's about 12M while the entire httpd-trunk checkout is 223M, so it's >> about a 5% size increase.) > > IIRC just that. Most developers (committer or not) don't need it. When you consider that it would be really nice if people throwing new modules at trunk would stop to at least outline them (as I did with mod_fcgid before Jeff and others jumped in to fill in the descriptions), that would be considerable progress. Let's just add the docs build. Ripping apart the docs build, you may as well pull all the source .xml's as well. This may be something to consider for the release tarball, but for dev checkouts the current schema is just odd. I would not mind if we kept one repository and used it as an external, but I am really worried that we don't have moving targets on a tag, so in order to tag complete, it becomes necessary to substitute svn cp's for each svn external.
Re: docs-build as an svn external?
* Rich Bowen wrote: > Is there any particular reason *not* to have docs-build as an svn > external under the docs/manual directory? > > (It's about 12M while the entire httpd-trunk checkout is 223M, so it's > about a 5% size increase.) IIRC just that. Most developers (committer or not) don't need it. nd
Re: [mod_fcgid] Windows and TCP/IP
On 9 April 2010 13:39, Jeff Trawick wrote: > On Wed, Mar 31, 2010 at 10:56 AM, Darren Garvey > wrote: > > On 31 March 2010 15:49, Jeff Trawick wrote: > >> > >> On Wed, Mar 31, 2010 at 7:05 AM, William A. Rowe Jr. > >> wrote: > >> > On 3/31/2010 5:41 AM, Jeff Trawick wrote: > >> >> On Wed, Mar 31, 2010 at 6:26 AM, Darren Garvey > >> >> wrote: > > >> >>> Does anyone know if there is any other way to communicate with > >> >>> mod_fcgid on Windows besides anonymous pipes? > > >> > Isn't httpd 2.3 alpha mod_proxy_scgi ment to do this? > > >> mod_proxy_fcgi at least ;) (I meant to add that earlier) > >> > >> mod_proxy_* is httpd's way to route/loadbalance/manage connections to > >> externally managed servers of various types > > > Ahh, this might be what I'm looking for. Is > > http://mproxyfcgi.sourceforge.net/ the same thing? It looks like > > mod_proxy_fcgi is in trunk now but this link has a user guide. :) > > hmmm, looks like the same idea (hopefully that's a good sign)... > mod_proxy_fcgid in httpd trunk was started from scratch some 4 yrs > ago... > Ok so, does mod_proxy_fcgid in trunk work? It would be nice to test my FastCGI code with an external configuration (with async I/O) on Windows. For now I'm just using pipes which - apart from blocking on read/write - seem to work fine. > > Does mod_proxy_fcgi set FCGI_WEB_SERVER_ADDRS as per the FastCGI spec? > > That should be set when the TCP-based FastCGI application is spawned > and checked when a new connection from the web server/gateway is > accepted? > > I see PHP logic to check it, but spawn-fcgi (Lighttpd) and fcgistarter > (httpd) don't handle that automatically. (I think you'd need to > create a wrapper for your app that sets it, then tell > spawn-fcgi/fcgistarter/whatever to run the wrapper.) > Yes, of course. Silly question now I think about it. This is an installation-specific configuration variable, I guess PassEnv should do too. Thanks for your help. Cheers, Darren
Re: [mod_fcgid] Windows and TCP/IP
On Wed, Mar 31, 2010 at 10:56 AM, Darren Garvey wrote: > On 31 March 2010 15:49, Jeff Trawick wrote: >> >> On Wed, Mar 31, 2010 at 7:05 AM, William A. Rowe Jr. >> wrote: >> > On 3/31/2010 5:41 AM, Jeff Trawick wrote: >> >> On Wed, Mar 31, 2010 at 6:26 AM, Darren Garvey >> >> wrote: >> >> >>> I can't remember now if mod_fcgid used to support external FastCGI >> >>> daemons >> >>> or not, but mod_fastcgi did (via. FastCgiExternalServer IIRC). >> >> >> >> No; mod_fcgid only supports FastCGI app processes which it has spawned. >> >> >> >>> >> >>> Does anyone know if there is any other way to communicate with >> >>> mod_fcgid on >> >>> Windows besides anonymous pipes? >> > >> > Isn't httpd 2.3 alpha mod_proxy_scgi ment to do this? >> >> mod_proxy_fcgi at least ;) (I meant to add that earlier) >> >> mod_proxy_* is httpd's way to route/loadbalance/manage connections to >> externally managed servers of various types > > Ahh, this might be what I'm looking for. Is > http://mproxyfcgi.sourceforge.net/ the same thing? It looks like > mod_proxy_fcgi is in trunk now but this link has a user guide. :) hmmm, looks like the same idea (hopefully that's a good sign)... mod_proxy_fcgid in httpd trunk was started from scratch some 4 yrs ago... > Does mod_proxy_fcgi set FCGI_WEB_SERVER_ADDRS as per the FastCGI spec? That should be set when the TCP-based FastCGI application is spawned and checked when a new connection from the web server/gateway is accepted? I see PHP logic to check it, but spawn-fcgi (Lighttpd) and fcgistarter (httpd) don't handle that automatically. (I think you'd need to create a wrapper for your app that sets it, then tell spawn-fcgi/fcgistarter/whatever to run the wrapper.)
Re: Can I have two virtual hosts with same servername?
On Fri, Apr 9, 2010 at 6:43 AM, Michael Ni wrote: > I have a java project that resides in tomcat. Recently we needed to add > Wordpress (php project). > > We decided to go with Apache Server in front with virtual hosts with > mod_proxy_ajp. > > So far I have gotten different server names to work > > http://www.foobar.com > http://blog.foobar.com > > > ServerName www.foobar.com > > > AddDefaultCharset Off > Order deny,allow > Allow from all > > > ProxyPass / ajp://localhost:8009/ > ProxyPassReverse / ajp://localhost:8009/ > > > > ServerName blog.foobar.com > > ErrorLog "C:/Program Files/Apache Software > Foundation/Apache2.2/logs/error.log" > DocumentRoot "C:/Program Files/Apache Software > Foundation/Apache2.2/htdocs" > > > > > HOWEVER, > we want to do the following instead > http://www.foobar.com > http://www.foobar.com/blog > > why does the following NOT work? > > > ServerName www.foobar.com > > > AddDefaultCharset Off > Order deny,allow > Allow from all > > > ProxyPass / ajp://localhost:8009/ > ProxyPassReverse / ajp://localhost:8009/ > > > > ServerName www.foobar.com > ServerPath /blog > > ErrorLog "C:/Program Files/Apache Software > Foundation/Apache2.2/logs/error.log" > DocumentRoot "C:/Program Files/Apache Software > Foundation/Apache2.2/htdocs" > > > This shouldn't be on dev, it should be on users. Read the manual section on virtual hosts for an explanation of why what you tried does not work. However, it is trivial to do what you wanted: ServerName www.foobar.com AddDefaultCharset Off Order deny,allow Allow from all ErrorLog "C:/Program Files/Apache Software Foundation/Apache2.2/logs/error.log" DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs" ProxyPass /blog ! ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/
