httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas, Peter" <>
Subject RE: X.509 certificate against LDAP authentication
Date Wed, 03 Mar 2010 22:11:31 GMT
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 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?


> _____________________________________________ 
> From: 	Thomas, Peter  
> Sent:	Wednesday, March 03, 2010 4:20 PM
> To:	''
> 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,
> (w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910
>  << File: Thomas, Peter L. ( >> 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message