Client authorization against LDAP using client certificates

[Müller Johannes]

Hello,

we want to use client authorization against LDAP using client certificates on 
Apache webserver 2.2.
Unfortunately this is not possible with Apache webserver at the current state 
of development.
There have been third party modules (ModXAuthLDAP, mod_authz_ldap) in the past 
which did this task quite well.
But they haven’t been updated for years and therefore do not work with httpd 
newer than 2.0.
Therefore my company has put some effort in developing a reasonable solution 
for its needs.

Firstly let me describe why it is not possible for us to do this form of 
authorization with a default httpd.

The client connects using SSL and a client certificate. Mod_ssl receives the 
request and checks the validity of the certificate using CRLs. After that it 
sets the user field in the Apache request object to the cn of the certificate 
(SSLUserName SSL_CLIENT_S_DN_CN). Afterwards mod_auth_basic tries to 
authenticate the user against its configured provider, wich is LDAP in our 
case. This fails, because there is no password coming from the certificate, 
which is quite obvious.

As you can see the missing password in the authentication phase is our main 
problem.
We tried to use SSLOptions +FakeBasicAuth, but then we would have to set 
“password” as password for all users in our directory. This is definitely no 
solution.

Another solution we thought of was to just set the require directives, but the 
hook seems to never get called, because of the missing AuthType directive.

We have developed the following possible solutions, which involve changes to 
the apache source code.
I’d be interested in comments and my company would appreciate it, if a solution 
could be included in apache. I could also provide a patch.

Solution 1
Description
* Add a boolean directive AuthBasicUserFromCert to mod_auth_basic
* This should tell mod_auth_basic not to run the configured authentication 
provider if a remote user is set by mod_ssl
* If no user is set (client does not provide certificate), basic authentication 
is done
Implementation
* Register directive in mod_auth_basic.c
* Add branch in authentication function to return AUTH_GRANTED if directive and 
user is set
* Remove call to ap_note_auth_basic_failure() in mod_authnz_ldap.c to avoid 
password dialog although we have a certificate if authorization fails
Pros and cons
+ Fallback to basic authentication done easy
+ Does not conflict with AAA-model
+ No duplicate code as we don't have to duplicate basic auth functionality 
(compare solution 3)
- mod_authnz_ldap has to be modified, too. Maybe this is not needed in Apache 
2.3/2.4, because the call has been removed. 


Solution 2
Description
* Create new module mod_auth_cert which has to be hooked previous to 
mod_auth_basic
* This new module runs if AuthType is set to „Cert“ checks for the remote user 
to be set
* In case the user is set by mod_ssl, return OK
* Else fall back to basic authentication by calling mod_auth_basic somehow
* This can possibly be achieved by rewriting AuthType on the fly
Implementation
* Copy mod_auth_basic.c
* Rename to mod_auth_cert
* Remove needless code
* Register in hook previous to mod_auth_basic.c
* In case the user is set by mod_ssl, return OK
* Else change r→auth_type to „Basic“ ?? Did not work in tests!
Pros and cons
+ Very clean concerning the AAA-model, because mod_auth_basic has nothing to do 
with certificates in principle
+ No duplicate code as we don't have to duplicate basic auth functionality 
(compare solution 3)
- Dirty solution concerning rewriting the AuthType directive on the fly
- More difficult to implement
- Maybe impossible 


Solution 3
Description
* Duplicate mod_auth_basic
* Call it mod_auth_cert
* Add new directives AuthType „Cert“ and AuthCertProvider
* If remote user is set by mod_ssl do not run authentication provider and 
return OK
* Else du basic authentication using the provider
Implementation
* Copy mod_auth_basic.c
* Rename to mod_auth_cert.c
* Rename directives
* Add branch in authentication function to return AUTH_GRANTED if directive and 
user is set
* Remove call to ap_note_auth_basic_failure() in mod_authnz_ldap.c to avoid 
password dialog although we have a certificate if authorization fails
Pros and cons
+ Fallback to basic authentication done easy
+ Very clean concerning the AAA-model, because mod_auth_basic has nothing to do 
with certificates in principle
- Otherwise dirty, because mod_auth_cert should have nothing to do with basic 
authentication, either
- mod_authnz_ldap has to be modified, too. Maybe this is not needed in Apache 
2.3/2.4, because the call has been removed.
- Duplicate code 


Freundliche Grüße/Kind regards
Johannes Müller

I/TS1A-G - Web Infrastructure
T +49 8 9-12 54 57 92
[EMAIL PROTECTED] 

E.ON IS GmbH
Blutenburgstraße 18
80636 München
www.eon-is.com

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:
Dr. Marcus Schenck   Geschäftsführung/Managing Directors:
Werner Hecker (Vorsitzender/Chairman)   Jörg 

Re: Apache 2.2.9 default bindist/apr library problem

[Andy Wang]

William A. Rowe, Jr. wrote:


In the long term, we have to fix apr-util, really not httpd's problem,
to teach apr-util's apu_dso to hunt in each shlibpath dir and its
apr-1-config subdir.

Ahh I see.  So your thoughts are to fix the bindist relocation problem, 
having apr-util look in all the shlibpath dirs to find apr-util-1/* 
would be the solution.



As for traditional yet relocated builds, say with --prefix=/bogus/path
and installed in /usr/lib, well that will require an envvar fixup
regardless.



And envvar would really only be necessary if for some reason the shlib 
dir was one not specified via one of the platform's env variables.


I did file the following bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45327
against apache since the problem is the bindist stuff isn't handling 
this.  If you're plan is for apr-util to fix it, I can redirect the bug 
to APR.  However, do you have an idea of if you're thinking longer term 
(at least a few releases out) or shorter term workaround in envvars (or 
something like that) and then fixing apr-util longer term?  If it's the 
former I think we can handle the workaround in our apache builds and 
just watch out for the longer term fix.


Thanks,
Andy

Re: WebDav MOVE/COPY between servers

[Julian Reschke]

Rafa%u0142 wrote:

Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisał(a):

Rafał wrote:

Hello.
  My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.

Why? Do you have any clients that would use it?


I will use telnet. After the server work is done I will extend existing 
Vinetoolkit Webdav client to support this.



How do you intend to solve the authentication problem?


SAML2 tokens over GSS with delegations.


OK, seems you know what you do :-)

BR, Julian

Re: Apache 2.2.9 default bindist/apr library problem

[William A. Rowe, Jr.]

Andy Wang wrote:


In a non relocated installation, this really isn't a problem though 
right?  As long as the library remains in the path that the linker 
initially was told it'd be at, this is a non issue, and one would expect 
in a non SHLIB_PATH situation, that would be the case,


Exactly.  Based on apr-util's ./configure --prefix, you're done.


In a case where it is relocated, envvar just needs to be updated right?


As a workaround, yes.

In the long term, we have to fix apr-util, really not httpd's problem,
to teach apr-util's apu_dso to hunt in each shlibpath dir and its
apr-1-config subdir.

As for traditional yet relocated builds, say with --prefix=/bogus/path
and installed in /usr/lib, well that will require an envvar fixup
regardless.

Re: Apache 2.2.9 default bindist/apr library problem

[Andy Wang]

William A. Rowe, Jr. wrote:

Eric Covener wrote:


One case to keep on the radar:  There can be configuration mechanisms
for the loader outside of the SHLIB_PATH envvar.   If this is apr-util
in /usr/lib, so no shlib-path-var is in use, would we be able to find
/usr/lib/apr-util-1/apr_foo-1.so?

Do the various loaders permit an argument resembling
"apr-util-1/bar.so" to consult the non-envvar loader configuration?


The apr-util's apu-prefix=/foo becomes /foo/lib/apr-util-1/ so this is 
and
isn't addressed, and really can't be.  Unless dlopen supports finding 
these

'default' platform directories, we are at a loss.




In a non relocated installation, this really isn't a problem though 
right?  As long as the library remains in the path that the linker 
initially was told it'd be at, this is a non issue, and one would expect 
in a non SHLIB_PATH situation, that would be the case,


In a case where it is relocated, envvar just needs to be updated right?

Thanks,
Andy

Re: Fwd: [EMAIL PROTECTED] encoded slashes in the url with AllowEncodedSlashes

[William A. Rowe, Jr.]

Eric Covener wrote:


Bill: I saw your veto in the biug below, would that apply to restoring
the original behavior of AllowEncodedSlashes as well or just the
approach in one of the patches?

https://issues.apache.org/bugzilla/show_bug.cgi?id=35256


I have an interesting idea...

combine the decode and the get_parents, such that only an encoded slash
would have the text value "//" and only an encoded backslash would have
the value "\\"  It would then be up to the proxy to forward the original
URI value or up to the file system to reject such constructs.

It needs fleshing out, but these are canonically unique values after the
string has had get_parents applied.  Thoughts?

Re: WebDav MOVE/COPY between servers

[Rafa%u0142]

Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisał(a):
> Rafał wrote:
> > Hello.
> >   My name is Rafał Malinowski. I want (really, I have to) add one feature
> > to WebDav: support for MOVE/COPY with remote servers as 'Destination'.
> 
> Why? Do you have any clients that would use it?

I will use telnet. After the server work is done I will extend existing 
Vinetoolkit Webdav client to support this.

> How do you intend to solve the authentication problem?

SAML2 tokens over GSS with delegations.

Best Regards
  Rafał Malinowski


KUNG FU PANDA - nowa komedia twórców Shreka i Madagaskaru.
Zobacz zwiastun, ściągnij tapety, ogladaj galerie.
http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fkungfupanda.html&sid=399

Fwd: [EMAIL PROTECTED] encoded slashes in the url with AllowEncodedSlashes

[Eric Covener]

On Thu, Jul 3, 2008 at 4:23 AM, Zac Hansen <[EMAIL PROTECTED]> wrote:
> I have AllowEncodedSlashes in my conf.  I am calling
>
> https://myserver.com/foo.cgi/a/b%2fc/d
>
> In the docs for AllowEncodedSlashes, it says it doesn't mean they will be
> decoded.

I believe AllowEncodedSlashes' meaning has been changed since:
http://svn.apache.org/viewvc?view=rev&revision=104925

Paying special attention to the the commit message, the 404 behavior
should have been correct/expected (assuming literal '%2f' isn't what
the core handler should have found in the filesystem).

Bill: I saw your veto in the biug below, would that apply to restoring
the original behavior of AllowEncodedSlashes as well or just the
approach in one of the patches?

https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

-- 
Eric Covener
[EMAIL PROTECTED]

Re: WebDav MOVE/COPY between servers

[Julian Reschke]

Rafa%u0142 wrote:

Hello.
  My name is Rafał Malinowski. I want (really, I have to) add one feature 
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.


Why? Do you have any clients that would use it?

  As I looked into code and into specification such thing is allowed, but 
not implemented yet. I hope I'll have it done with some help from this 
list, and I hope it will not take more than one month of work ;)

  If someone wants to help me/have some good advice, I would appreciate it.
...


How do you intend to solve the authentication problem?

BR, Julian

DefaultType None directive

[Julian Reschke]

Hi,

looking at :


  --- Comment  #64 From Phil Ringnalda  2008-07-03 00:07:23 PST  [reply] 
---

While I don't have any real expectation of action coming from a comment on a
resolved bug, I still want to mention that the fix for this bug did not fix
this bug: it made it _possible_ to "remove default MIME-type" while ignoring
the part of comment 55 about "a) remove DefaultType from the standard
httpd.conf.in file," which still combines a text/plain default with simply
awful advice about using text/plain "If your server contains mostly ... HTML
documents."


It seems Phil is correct in that this issue shouldn't be closed until 
the default httpd.conf also is changed.


Furthermore, has backporting been considered?

BR, Julian