Re: SASL authentication, authorization and data encryption support (ITS#501)

[Kurt@OpenLDAP.org]

At 05:54 PM 4/11/00 GMT, gombasg@inf.elte.hu wrote:
>Full_Name: Gábor Gombás
>Version: 2.0-devel
>OS: Debian Linux 2.2
>URL: http://valerie.inf.elte.hu/~gombasg/ldap/openldap-sasl.patch
>Submission from: (NULL) (157.181.161.14)
>
I won't have significant time to review the changes for a bit...
I just make a few quick comments (without looking at the code).
>
>I've managed to get SASL authentication, authorization and data encryption
>working for
>OpenLDAP 2.0-devel. It was inspired by (and contains code from) the patch
>created
>by Mark Adamson.

Great.  Please ping with Mark to ensure any changes he's made
since submitting his patch are appropriately integrated.

>The patch contains:
>
>- SASL support for the programs in the clients/tools directory. New command line
>flags:
>  '-C' to use Cyrus SASL authentication (the small letter 'c' was already used
>for
>  other purposes in some of the programs), '-m mech' to specify the SASL
>mechanism and
>  '-Z authzid' to specify an authorization ID (see below)

We had a prior discusson on which flags to use for various SASL/TLS
options.  It may have been private.  I'll see if I can locate the
post (and provide it to -devel).  Modification to use the previously
choosen flags *should* be a straight forward...

>- Security layer support changes in liblber

I'll assume you've read previous posts about LDAP/LBER layering
issues [just to be aware of "the vision"... need not be implemented
by your code]

>- 3 new config. options for slapd: SASLMinSSF, SASLMaxSSF and SASLDefaultDb. The
>first
>  two enables the setting of the minimal/maximal SSF. SASLDeafultDb marks a
>database
>  definition to be used when the client does not provide a DN for SASL bind and
>the DN
>  needs to be determined from the authentication ID

Note that the client provided DN MUST NOT be used to locate the entry
to authenticate as.  The DN MUST only be used to select a subset of
the possible realms returned.  See previous discussions (in response
to Marks patch, likely in -bugs or -devel archives).

>- I've added a new mutex to the Connection structure to block all input between
>sending
>  the final result of the SASL bind and installing the security layer functions
>to
>  the socket. Without it ber_get_next() tries to interpret encrypted data and
>fails which
>  causes the connection to be dropped just after the bind

Hmmm... well... I think there a better approach [connection state
machine] to resolving this issue... but don't mind the mutex approach
for now.

>- The ldbm backend supports SASL authentication and two forms of authorization.
>If the
>  client did not specify a DN to bound to, it's determined from the given
>authorization
>  ID using the "externalAuthName" attribute.

The provided DN MUST NOT be used to determine the authorization ID.
The authorization ID, if not provided by the client, MUST be derived
from the authentication ID.

I have some thoughts on this should be implemented... (basically
configuration options which map authentication id to DN via
regex).  I'll dig up the private discussions and post a summary
to -devel.

>The authorization ID can be
>specified
>  either as "dn:<dn>" or as "u:<userid>" as the authmech draft says. The
>permissions
>  for the authorization can be stored in either the authenticated entry's
>"allowAuthorizeAs"
>  attribute or in the target entry's "allowAuthorizationTo" attribute. Both are
>regular
>  expressions which the authorized/authenticated DN must match
>
>What's missing:
>- Client-side configuration of the desired data integrity and encryption level
>
>Gabor
>
>
>