Proposal for SASL authorization

[Mark Adamson <adamson@andrew.cmu.edu>]

  The following text is a proposal for how SASL authorization should be
implemented in OpenLDAP. It is based on a discussion between Kurt Zeilenga
of OpenLDAP, Larry Greenfield of Carnegie Mellon for his expertise in
SASL, and myself. I hope OpenLDAP users will offer opinions on
improvements or failings of this proposal.


  The current SASL implementation in OpenLDAP is adequate for
authenticating to the slapd server as a SASL identity, but it does not
allow for exploiting the SASL feature of authorizing to another
identity. This feature is important for any application that is to act
on the behalf of another entity. A simple example of the use of this
feature is a web server interface for searching LDAP. A user may
authenticate themself to the web server through any of many available
means, and the web server can authenticate itself to the LDAP server as
a web server identity. Then the web server would like to authorize to
the web client's identity so that the search is carried out with their
credentials, and all access is controlled by the LDAP server.

  When an LDAP connection makes a SASL request to authorize to another
identity, it is up to the SASL server application (slapd) to make the
decision as to whether the authenticated identity be allowed to change
to the authorization identity. It is up to the server administrator to
write rules about authorizing from a source identity to a destination
identity. The rules can either state that a given source identity can
authorize to a set of destination identities, or state that a set of
source indentities can authorize to a given destination identity. The
rules will always state what is allowed, not what is denied.

  The authorization rules will be stored in the LDAP data space. This
will make them easier to manage than if they were in configuration
files. Within an LDAP entry that someone has authenticated to, there can
be "source rules" telling to what DNs that entry can authorize. Within
any entry there can be "destination rules" telling who can authorize to
that entry. When an authorization request is being processed, both the
source and destination rules will be checked, and if any of them allows
the authorization, the request is honored. The order of checking the
rules is irrelevant in terms of changing the outcome of the decision.

  The source and destination rules will be stored in their own
attributes. Two different attribute names must be used to prevent
ambiguity, yet the OIDs for the attributes are not yet determined. The
attributes are multivalued, and the values within the attributes will be
LDAP URIs representing search operations. The names of the attributes 
will be:

  saslAuthzTo       source rules      -- who this DN may become
  saslAuthzFrom     destination rules -- who may become this DN

  The decision of which type of rule to use will depend on the
situation. For example, if the set of people who may become a given
identity can easily be written as a search filter, then a single
destination rule could be written. If the set of people is not easily
defined by a search filter, and the set of people is small, it may be
better to write a source rule in the entries of each of those people.

  The process of authorizing in SASL consists of first authenticating
oneself to the LDAP server using a mechanism such as Kerberos V4, and
then requesting that the bound identity be changed to another.
Authenticating with the KERBEROS_V4 mechanism to LDAP will leave the
connection bound with a pseudo-DN similar to

	UID=ADAMSON.LDAP+REALM=ANDREW.CMU.EDU

for a Kerberos V4 instance of "adamson.ldap@andrew.cmu.edu". In order to
check for source rules, that SASL name must be converted to a DN to find
the source rules. It is reasonable to assume that in most deployments of
LDAP there is enough data in the SASL name to uniquely match it to an
LDAP distinguished name. The conversion process will depend on the site
specific layout of the directory or on custom attributes added to the
schema. It should be possible to write a pattern matching regular
expression that will convert the SASL name into an LDAP URI that could
be used to find a unique LDAP DN. The regexp will consist of two parts,
with the first being a matching pattern and the second being a replace
pattern, similar to the "s" command in Larry Wall's Perl.

  The example SASL name above is for the Kerberos V4 mechanism. Other
mechanisms exist, and can produce SASL names with different forms. For
this reason, a matching pattern will need to know what mechanism
produced the SASL name. When the SASL name is given to the matching
pattern, the mechanism which produced it will be prepended:

  MECH=KERBEROS_V4+UID=ADAMSON.LDAP+REALM=ANDREW.CMU.EDU


  OpenLDAP slapd may have multiple backend databases, covering different
areas of an LDAP namespace. The authorization process is not tied to a
specific backend, so the pattern matching regexp cannot be placed in the
LDAP data space. These pattern matching regexp will be given in one or
more configuration options in the slapd.conf file. A new option, called
"saslregexp" will be added to the configuration file, and it will
require exactly two arguments, the matching pattern and the replace
pattern.  If the above SASL name was to be converted to the DN

  uid=adamson,ou=Account,dc=andrew,dc=cmu,dc=edu

The saslregexp option could be written as

  saslregexp 
    MECH=KERBEROS_V4\+UID=(.*)\.LDAP\+REALM=(.*)\.CMU\.EDU  
    ldap://ldap2.andrew.cmu.edu/uid=$1,ou=Account,dc=$2,dc=cmu,dc=edu

This example matching pattern checks that the mechanism was KERBEROS_V4,
the .ldap instance of the user was given, and the realm was a subdomain
of cmu.edu.  The replace pattern inserts the username and subdomain into
the URI, using the known directory structure on the ldap2.andrew.cmu.edu
LDAP server.  If it were also possible to authenticate in the "cmu.edu"
realm itself, another saslregexp rule could be given for that other
case, since the cmu.edu realm will not match the above matching pattern.

  The SASL name can be compared against the saslregexp options in the
order they were found in the configuration file slapd.conf, and the
first to make a match will be the one used. The replace string will then
be used to generate an LDAP URI which will be used to search for a
DN. If more than one DN matches the URI, the conversion is considered
ambiguous, and an error is returned to the SASL authorization request.
For a single match, that DN can then be checked for source rules, and if 
any match the requested authorization DN, the authorization request is
honored. If none match, the authorization DN is then sought and its
destination rules are matched against the authentication DN. If any
match, the authorization request is honored, and if not, the request
receives an "insufficient access" error message.

  This framework provides for conversion from the SASL name space and 
the LDAP name space. It then establishes how the slapd server is to
determine if SASL authorization requests should be honored. The LDAP
administrators will have the ability to write simple LDAP URIs as
rules for allowing authorization, either from one identity to another,
or as a set of identities that may change to a given identity. We will
then be able to exploit SASL authorization for a variety of useful
purposes.




  -Mark Adamson
   Carnegie Mellon