[...] 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?
