Eric Covener wrote:
On Tue, Sep 8, 2009 at 10:09 AM, Udo Rader<list...@bestsolution.at> wrote:
Graham Leggett wrote:
SSLOptions +FakeBasicAuth
AuthName "Snake Oil Authentication"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPRemoteUserAttribute uid
AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?subjectDN?one
require valid-user
</Location>
For obvious reasons, authentication fails, because mod_ssl sends "password"
as the password for any "faked" basic auth user to the underlying
authentication mod_authzn_ldap module, see the "FakeBasicAuth" section here
[1].
And of course, it is impossible to set "password" as password for everyone
in the LDAP DIT.
What we basically "needed" was our clients authenticate using their
certificates and then have mod_authnz_ldap fetch their user names (uid)
based on the certificates' subjects (or similar).
I never understood how FakeBasic was usable, but nevertheless you
don't want "AuthBasicProvider LDAP" in this case. This is the bit
that's asking LDAP to check the users password -- you just want the
authorization directives.
Yes, but the problem is that the "fake" user name set by mod_ssl is the
certificate's subject, eg.
/C=AT/ST=Austria/L=Innsbruck/O=Example.com/OU=The Test/CN=Foo
Bar/emailaddress=foo....@example.com
Typically, certificate based authentication needs to be "supported" by
LDAP, the latter translating the certificate subjects into "real"
usernames, useable by external applications via REMOTE_USER.
Once authentication is done, LDAP based authorization should take effect.
So, if I see it right, besides the hard coded "password", the missing
bit currently is the mapping between certificate subjects and "real"
user names (let them be the complete DN from the DIT or just an attribute).
--
Udo Rader, CTO
http://www.bestsolution.at
http://riaschissl.blogspot.com
