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

RE: SASL EXTERNAL TLS question

Hmm, so let me restate my requirement:
Requirement:

Use OpenLDAP with TLS, with server supplying digital certificate and "demand"ing client certificate.  Based on client certificate, bind the client application to an entry.

Like Howard and Kent say, my LDAP client application does get authenticated to the server.  And I don't need to involve SASL at all.  However, I have the following default access control mechanism:

access to *
	by self write
	by users read
	by anonymous auth

The way I read the above policy is that if I created an entry, I can write to it, others can only read.  So, if one client application created, say, three entries of a particular objectClass, only that application can modify it. 

Doesn't the client application need to bind itself to the server in order to do just that?  Or are you guys saying that just authenticating itself to the server is sufficient enough to fulfill the above access control policy?  I am using JNDI to access LDAP.  May be JNDI requires me to bind when LDAP doesn't really.

Consider that I have a new objectClass defined, called A, that has a name attribute.  If one client app adds three As and another four, I want both of them to have read access to all seven, but first one with write access to first three and the second one with write access to last four.

Both the client apps have a dig cert each that server can verify.  Is that good enough to fulfill the access control policy?

Boy, do I have this concept completely wrong?

Thanks,
-Milind
--- Begin Message --- 
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Kent Soper

> Dieter Kluenter writes:

> > Hello,
>
> > "Milind Khandekar" <MKhandekar@savi.com> writes:
>
> >> Requirement:
> >>
> >> Use OpenLDAP with TLS, with server supplying digital
> certificate and
> >> "demand"ing client certificate.  Based on client
> certificate, bind the
> >> client application to an entry.
> >>
> >> My progress thus far:
> >>
> >> The two way certificate exchange and client authentication works.
> >>
> >> Problem:
> >>
> >> I can't bind the client to an existing entry.
> >>
> >> I understand that I need to use SASL external.  I just can't figure
> >> out how I use it.  I looked around everywhere on OpenLDAP, and I am
> >> quite sure that there is a small HOWTO somewhere that will describe
> >> exactly what needs to be done.  Can any kind soul point me to it?
>
> > You have to create X.509 certificates for all your users.
> For this to
> > work properly, you might need to change openssl.conf to fit
> into your
> > directory scheme, that is probabely additional ou's c', o's.
>
> > To make use of sasl external mechanism you have to start tls, i.e.
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> > dieter@marin:~> ldapwhoami -Y EXTERNAL -ZZ
> > SASL/EXTERNAL authentication started
> > SASL username: CN=Dieter Kluenter,OU=partner,O=avci,C=de
> > SASL SSF: 0
> > dn:cn=dieter kluenter,ou=partner,o=avci,c=de
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
>
> > SASL username is read from the certificate and than parsed
> against an
> > entry, so make sure that the distinguished names are equal.
>
> > -Dieter
>
> I probably have a simple setup for my slapd, but the DN of
> the certificate
> does not have to parsed to match an entry in my directory.
> If the client
> cert can be verified by the server, client is authenticated.  If a bad
> client cert is used, client is not authenticated.

Correct. SASL authentication merely determines whether the server will
believe the user's assertion of the user's identity. Whether or not the
identity exists in LDAP is not a consideration. That's the whole point of
SASL, it's an external authentication system which uses out-of-band means to
validate an identity.

> I didn't even have a sasl-regexp in my slapd.conf to get it to work.
> However, Kurt Zeilenga did suggest to me that I would need to do some
> mapping of the dn's.

Mappin the DNs is merely a convenience. It's of greatest value when you
support multiple different means of authenticating, and you want to
coordinate them all with an existing user entry in the directory. This is
desirable for some purposes like e.g. pam_ldap, which must look up attributes
of a user after authenticating the user. In this case, you really want the
authentication ID to equate to the DN of an entry in the directory so you can
find the attributes of interest. But if all you needed was a boolean result
is/is-not authenticated, then mapping would be irrelevant.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

--- End Message ---