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

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

At 12:10 AM 4/13/00 +0200, GOMBAS Gabor wrote:
>> 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]
>I've read some messages in the archives but I'm not sure if you are
>talking about the same thing. Please tell me exaclty which thread were you
>thinking of.


>Actually, I had my own opinion of what could be done: a
>mechanism which enables independent I/O functions to be stacked on top of
>each other, something like the BIOs in OpenSSL. With this approach,
>liblber should know nothing about security, it would just call the I/O
>functions in the order they were added to the socket and pass data between
>them. Whether a layer does encryption, read-ahead buffering or something
>else, liblber should not care anything about.


>But supporting this
>functionality would require the complete rewrite of the I/O routines in

Yes.  This is why I said you did not need to resolve this problem
today.  I don't mind if the solution today is not terrible flexible
or extensible as long as it allows for implementation of SASL
(security layer), TLS, or IPSEC.  The implementation need only to
support one layer at a time.

>> 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).
>It can be done by simply elimitating my find_by_dn() function in
>back-ldbm/sasl.c.  However, the only threat of using the bind DN is a false
>authentication failure when the specified DN and the authentication ID do
>not match (the check is based on the value of the "externalauthname"
>attribute - if it contains the given authentication ID, authentication is
>OK, else authentication fails).
>I think the realm selection is already done in do_bind() when it calls
>select_backend() with the given bind DN.

I'm about to change this code.  In particular, the sasl_bind()
call will be moved to the frontend.


[discussion regarding in-directory representation of authorization
information ducked].