[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SSL authentication

On Monday, March 29, 2004, at 01:49 PM, Howard Chu wrote:
[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Donn Cave

We've been using a hack to simple bind to authenticate with SSL
certificates, in 2.1 and 2.2, mainly so we could support client
libraries on some MS Windows & MacOS X platforms that have SASL
but no `external' option.  The client basically just sends some
standard stuff, that would not be valid in a normal simple bind,
to signal it wants a certificate bind.  It's 100 or so lines of
extra code in bind.c, but mods to existing code are limited to
one spot.

I used to have code for this in OpenLDAP 2.0 (pre-release); basically if the
client did a simple Bind with a DN and no password, and provided a client
cert, and the client cert DN matched the simple Bind DN then I treated it as
a successful authentication. That fell by the wayside when SASL/EXTERNAL came
along. Sometimes SASL gets to be enough of a headache that I'm tempted to
resurrect that code, but the current approach works...

... unless it doesn't. Our Windows guys blanched at the thought of
trying to support openldap and cyrus-sasl client libraries. It turns
out that very recent versions of the platform (XP?) support `external'
in their native crypto security layer, but we can't expect that site-wide.
Maybe MacOS X 10.3's SASL supports external, 10.2 doesn't. So the way
I see it, I'm committed to making this hack, or something like it,
because of widespread lack of support for client side SASL external.

That's about the way I did it, by the way, except as I recall it was
easier to require a standard "password" than no password, because of
the flow of logic in do_bind().  I can take the certificate DN for
bind DN, or it can also be a standard quantity ("cn=external"), since
I couldn't think of any reason the client should have to know this
value and in fact it can be kind of awkward.  So the application can
just supply two standard phrases and get authenticated automatically,
with all the work limited to the SSL layer.  The application programmers
have not complained.

	Donn Cave, donn@u.washington.edu