Re: Status of Cyrus Sasl support in Dev version

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:45 PM 5/8/00 -0700, Booker C. Bense wrote:
>On Mon, 8 May 2000, Kurt D. Zeilenga wrote:
>
>> At 09:38 PM 5/4/00 -0700, Booker C. Bense wrote:
>> >- I just did a cvs update from the current_dev tree and noticed
>> >that you are now checking for the cyrus sasl libraries. This is
>> >great! However, I poked around in the source and the support 
>> >seems pretty incomplete ( at least in back-bdb2 ),
>> 
>> Most of the code is in the frontend... and I haven't botherred
>> to update back-bdb2 as it's not being actively developed.  We
>> likely won't get moving on a replacement backend until post
>> 2.0-beta.
>
>- Are you re-engineering the back end interface?

Yes.

In the current code, SASL is 100% frontend, ie: SASLdb only.
There is some backend calls to allow backend storage of
credentials and authorization information, but work here
is needed [the existing backend (ldbm) calls ARE NOT
hooked in].

>It seems to 
>me that sasl is pretty hard to do unless you move it up a 
>layer.

Yes.  SASL needs to managed by the frontend.

>What backend should I be looking at for the cyrus 
>stuff?

None.  Look as slapd/{bind,sasl}.c

>I looked at the code in slapd/bind.c and slapd/sasl.c and it 
>looks like the backend bind doesn't really have to do anything
>other than map the sasl identity to the corresponding DN. 

This is the sticky part.

Background:

The current LDAPext thoughts [AuthMeth vs RFC 2251] are that
the SASL bind should not be required to carry a DN in the
name field and, if it does, it should only be [per LDAPext
discussions] be used for limiting the number of realms provide
in the initial bind response [where this makes sense].  [I
don't think Cyrus supports multiple realms yet].

So, what the frontend commonly has, in LDAP AuthMeth terms,
is a SASL mechanism specific authentication identity.  For
directory secrets, we need to provide Cyrus with callback to
the slapd frontend which maps the authentication identity to
a DN.  Once we have the DN, we hook into the appropriate
backend for the secret.  The question here is:  how should we
map SASL authentication to a DN.  I suggest by regex 
which would act upon triples of the form MECHANISM:REALM:username
and produce DNs.  The regex(es) would be provided in slapd.conf.

This, of course, is just simple authentication... we need
authorization as well.

>- Are you going to support encryption for those sasl methods
>that have it? 

Yes.  I think most of this code was committed, but there might
be one or two pieces left in Issue Tracking System for review
(These might be client side, I forget).  I also need to review
the code as a whole to ensure all the various
authentication/encryption state changes are properly handled.
But I can do this post commit.

>> 
>> >is there anything I can do to help with the work? 
>> 
>> I need to post a brief summary of what I think needs
>> getting done... later this week...
>> 
>> Of course, you're more than welcomed to jump on in.
>> 
>
>- I've run into a work project that would be ideally implemented
>as an ldap backend, but it does require sasl authentication and
>encryption of the data stream( either sasl or TLS ) for the server and
>of course appropriate support in the client libraries. 

TLS should be there, but we still need to implement
SASL "EXTERNAL" support.  [volunteers welcomed]

>How close is this to being possible?

>From SASLdb, very soon.  I need to do some testing of changes
I recently made [moving the primary SASL call to the
frontend].

>What would be a good testing environment? 

A couple of boxes running your favorite UNIX (or UNIX-like)
OS should be good enough.  I suggest having Cyrus SASL,
codes to support DIGEST-MD5 with integrity/privacy
protections, Kerberos V (MIT or Heimdal), and OpenSSL
(for TLS).