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

[gombasg@inf.elte.hu]

On Tue, 11 Apr 2000, Kurt D. Zeilenga wrote:

> 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...

Ok, I've read it now. I plan to change my version of the code soon and
submit the changes.

> 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
liblber. 

> 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.

> 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.

Agreed. If the client does not provide an authorization ID or the provided
ID matches the authenticated entry, authentication is accepted and no
further checks regarding authorization are made.
 
> 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.

I'd like to see this information represented in the directory itself, it
gives more flexibility.

I'd also like to hear comments about checking if authorization should be
accepted or rejected. Suppose A is the authenticated entry, and the client
wants to authorize as entry B. My code supports two forms of access
checking now: 

1. If the "allowauthorizeas" attribute of entry A contains a regexp which
maches the DN of entry B, then authorization is accepted (I called it
"forward authorization"). Pro: easy setup for proxy-like clients. Contra:
maybe TOO powerful; anyone who can modify the "allowauthorizeas" attribute
of an entry it can authorize as has nearly full control of the database.

2. If the "allowauthorizeto" attribute of entry B contains a regexp which
maches the DN of entry A, then authorization is accepted (I called it
"reverse authorization"). Pro: fine-grained access control. Contra: needs
much more administration for proxy-like clients.

Personally I prefer the second approach (everyone can decide whether
he/she trusts a proxy or not), but for many setups the first one would be
satisfactory and much easier to administer.

Gabor

---
Gabor Gombas                                       Eotvos Lorand University
E-mail: gombasg@inf.elte.hu                        Hungary