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

HEADS UP: SASL Changes (Round One)

I have commited a number of changes to our SASL codes.

The most visible external change is the replacement of
ldap_sasl_negotiated_bind_s() with ldap_sasl_interactive_bind_s().
As the name suggests, it's designed to interact with the
user.  It uses an application provided routine for prompting.
I've provided a routine for our "private" use by our
client/tools.  I intend to modify the routine a bit to cut
down on some unnecessary interactions (such as authorization
identity specification) and to allow specification of values
via the command line (old -U, -X, -W, -w are no-ops at the
moment).  I'll like change the API for ldap_sasl_interactive_bind_s()
to directly expect the specification of the interact routine
to use, and provide a mechanism for applications to provide
context (which may be used to provide default values).

I've also replaced -E/-I with -O.  -O expects a string
representing SASL security properties.

I've disabled security layers as more work is needed to
fully support them.

The internals have also changed significantly.  The
SASL context is now created immediately after the connect
and used/reused as needed.  I've also put hooks in so
that someone notify SASL when TLS (or other) security
layer has been established.

I've reworked SLAPD with similar changes.

This is a 'work in progress' and is a bit rough around
the edges.

Round two will mostly focus on implementing (optional)
restrictions of server operations based upon what
authentication/security in place.  This will include
options to require strong authentication, disallow
updates (or reads) unless privacy protections in place,
etc.  Not that these are operational restrictions
(as outlined in RFC 2251/2829/2830), not access control

Note, I'll leave the following to others:
	SASL/StartTLS rebind issues

The later issue will like require structuring of our referral
management code.

Round three (or later) will sort out authorization issues.