sasl.sdf

OpenLdap是LDAP的开源项目

The search pattern can contain any of the regular expression
characters listed in {{regexec}}(3C). The main characters of note
are dot ".", asterisk "*", and the open and close parenthesis "("
and ")".  Essentially, the dot matches any character, the asterisk
allows zero or more repeats of the immediately preceding character
or pattern, and terms in parenthesis are remembered for the replacement
pattern.

The replacement pattern will produce either a DN or URL refering
to the user.  Anything from the authentication request DN that
matched a string in parenthesis in the search pattern is stored in
the variable "$1". That variable "$1" can appear in the replacement
pattern, and will be replaced by the string from the authentication
request DN. If there were multiple sets of parentheses in the search
pattern, the variables $2, $3, etc are used.

H3: Direct Mapping

Where possible, direct mapping of the authentication request DN to
the user's DN is generally recommended.  Aside from avoiding the
expense of searching for the user's DN, it allows mapping to
DNs which refer to entries not held by this server. 

Suppose the authentication request DN is written as:

>	uid=adamson,cn=example.com,cn=gssapi,cn=auth

and the user's actual LDAP entry is:

>	uid=adamson,ou=people,dc=example,dc=com

then the following {{EX:authz-regexp}} directive in {{slapd.conf}}(5)
would provide for direct mapping.

>	authz-regexp 
>	  uid=([^,]*),cn=example.com,cn=gssapi,cn=auth
>	  uid=$1,ou=people,dc=example,dc=com

An even more lenient rule could be written as

>	authz-regexp
>	  uid=([^,]*),cn=[^,]*,cn=auth 
>	  uid=$1,ou=people,dc=example,dc=com

Be careful about setting the search pattern too leniently, however,
since it may mistakenly allow persons to become authenticated as a
DN to which they should not have access.  It is better to write
several strict directives than one lenient directive which has
security holes.  If there is only one authentication mechanism in
place at your site, and zero or one realms in use, you might be
able to map between authentication identities and LDAP DN's with a
single {{EX:authz-regexp}} directive.

Don't forget to allow for the case where the realm is omitted as
well as the case with an explicitly specified realm. This may well
require a separate {{EX:authz-regexp}} directive for each case, with
the explicit-realm entry being listed first.

H3: Search-based mappings

There are a number of cases where mapping to a LDAP URL may be
appropriate.  For instance, some sites may have person objects
located in multiple areas of the LDAP tree, such as if there were
an {{EX:ou=accounting}} tree and an {{EX:ou=engineering}} tree,
with persons interspersed between them.  Or, maybe the desired
mapping must be based upon information in the user's information.
Consider the need to map the above authentication request DN to
user whose entry is as follows:

>	dn: cn=Mark Adamson,ou=People,dc=Example,dc=COM
>	objectclass: person
>	cn: Mark Adamson
>	uid: adamson

The information in the authentication request DN is insufficient
to allow the user's DN to be directly derived, instead the user's
DN must be searched for.  For these situations, a replacement pattern
which produces a LDAP URL can be used in the {{EX:authz-regexp}}
directives.  This URL will then be used to perform an internal
search of the LDAP database to find the person's authentication DN.

An LDAP URL, similar to other URL's, is of the form

>	ldap://<host>/<base>?<attrs>?<scope>?<filter>

This contains all of the elements necessary to perform an LDAP
search:  the name of the server <host>, the LDAP DN search base
<base>, the LDAP attributes to retrieve <attrs>, the search scope
<scope> which is one of the three options "base", "one", or "sub",
and lastly an LDAP search filter <filter>.  Since the search is for
an LDAP DN within the current server, the <host> portion should be
empty.  The <attrs> field is also ignored since only the DN is of
concern.  These two elements are left in the format of the URL to
maintain the clarity of what information goes where in the string.

Suppose that the person in the example from above did in fact have
an authentication username of "adamson" and that information was
kept in the attribute "uid" in their LDAP entry. The {{EX:authz-regexp}}
directive might be written as

>	authz-regexp 
>	  uid=([^,]*),cn=example.com,cn=gssapi,cn=auth  
>	  ldap:///ou=people,dc=example,dc=com??one?(uid=$1)

This will initiate an internal search of the LDAP database inside
the slapd server. If the search returns exactly one entry, it is
accepted as being the DN of the user. If there are more than one
entries returned, or if there are zero entries returned, the
authentication fails and the user's connection is left bound as the
authentication request DN.

The attributes that are used in the search filter <filter> in the
URL should be indexed to allow faster searching. If they are not,
the authentication step alone can take uncomfortably long periods,
and users may assume the server is down.

A more complex site might have several realms in use, each mapping
to a different subtree in the directory.  These can be handled with
statements of the form:

>	# Match Engineering realm
>	authz-regexp
>	   uid=([^,]*),cn=engineering.example.com,cn=digest-md5,cn=auth
>	   ldap:///dc=eng,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
>
>	# Match Accounting realm
>	authz-regexp
>	   uid=([^,].*),cn=accounting.example.com,cn=digest-md5,cn=auth
>	   ldap:///dc=accounting,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
>
>	# Default realm is customers.example.com
>	authz-regexp
>	   uid=([^,]*),cn=digest-md5,cn=auth
>	   ldap:///dc=customers,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))

Note that the explicitly-named realms are handled first, to avoid
the realm name becoming part of the UID.  Also note the use of scope
and filters to limit matching to desirable entries.

See {{slapd.conf}}(5) for more detailed information.


H2: SASL Proxy Authorization

The SASL offers a feature known as {{proxy authorization}}, which
allows an authenticated user to request that they act on the behalf
of another user.  This step occurs after the user has obtained an
authentication DN, and involves sending an authorization identity
to the server. The server will then make a decision on whether or
not to allow the authorization to occur. If it is allowed, the
user's LDAP connection is switched to have a binding DN derived
from the authorization identity, and the LDAP session proceeds with
the access of the new authorization DN.

The decision to allow an authorization to proceed depends on the
rules and policies of the site where LDAP is running, and thus
cannot be made by SASL alone. The SASL library leaves it up to the
server to make the decision. The LDAP administrator sets the
guidelines of who can authorize to what identity by adding information
into the LDAP database entries. By default, the authorization
features are disabled, and must be explicitly configured by the
LDAP administrator before use.


H3: Uses of Proxy Authorization

This sort of service is useful when one entity needs to act on the
behalf of many other users. For example, users may be directed to
a web page to make changes to their personal information in their
LDAP entry. The users authenticate to the web server to establish
their identity, but the web server CGI cannot authenticate to the
LDAP server as that user to make changes for them. Instead, the
web server authenticates itself to the LDAP server as a service
identity, say,

>	cn=WebUpdate,dc=example,dc=com

and then it will SASL authorize to the DN of the user. Once so
authorized, the CGI makes changes to the LDAP entry of the user,
and as far as the slapd server can tell for its ACLs, it is the
user themself on the other end of the connection. The user could
have connected to the LDAP server directly and authenticated as
themself, but that would require the user to have more knowledge
of LDAP clients, knowledge which the web page provides in an easier
format.

Proxy authorization can also be used to limit access to an account
that has greater access to the database. Such an account, perhaps
even the root DN specified in {{slapd.conf}}(5), can have a strict
list of people who can authorize to that DN. Changes to the LDAP
database could then be only allowed by that DN, and in order to
become that DN, users must first authenticate as one of the persons
on the list. This allows for better auditing of who made changes
to the LDAP database.  If people were allowed to authenticate
directly to the priviliged account, possibly through the {{EX:rootpw}}
{{slapd.conf}}(5) directive or through a {{EX:userPassword}}
attribute, then auditing becomes more difficult.

Note that after a successful proxy authorization, the original
authentication DN of the LDAP connection is overwritten by the new
DN from the authorization request. If a service program is able to
authenticate itself as its own authentication DN and then authorize
to other DN's, and it is planning on switching to several different
identities during one LDAP session, it will need to authenticate
itself each time before authorizing to another DN (or use a different
proxy authorization mechanism).  The slapd server does not keep
record of the service program's ability to switch to other DN's.
On authentication mechanisms like Kerberos this will not require
multiple connections being made to the Kerberos server, since the
user's TGT and "ldap" session key are valid for multiple uses for
the several hours of the ticket lifetime.


H3: SASL Authorization Identities

The SASL authorization identity is sent to the LDAP server via the
{{EX:-X}} switch for {{ldapsearch}}(1) and other tools, or in the
{{EX:*authzid}} parameter to the {{lutil_sasl_defaults}}() call.
The identity can be in one of two forms, either

>	u:<username>

or

>	dn:<dn>

In the first form, the <username> is from the same namespace as
the authentication identities above. It is the user's username as
it is refered to by the underlying authentication mechanism.
Authorization identities of this form are converted into a DN format
by the same function that the authentication process used, producing
an {{authorization request DN}} of the form

>	uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth

That authorization request DN is then run through the same
{{EX:authz-regexp}} process to convert it into a legitimate authorization
DN from the database. If it cannot be converted due to a failed
search from an LDAP URL, the authorization request fails with
"inappropriate access".  Otherwise, the DN string is now a legitimate
authorization DN ready to undergo approval.

If the authorization identity was provided in the second form, with
a {{EX:"dn:"}} prefix, the string after the prefix is already in
authorization DN form, ready to undergo approval.


H3: Proxy Authorization Rules

Once slapd has the authorization DN, the actual approval process
begins. There are two attributes that the LDAP administrator can
put into LDAP entries to allow authorization:

>	authzTo
>	authzFrom

Both can be multivalued.  The {{EX:authzTo}} attribute is a
source rule, and it is placed into the entry associated with the
authentication DN to tell what authorization DNs the authenticated
DN is allowed to assume.  The second attribute is a destination
rule, and it is placed into the entry associated with the requested
authorization DN to tell which authenticated DNs may assume it.

The choice of which authorization policy attribute to use is up to
the administrator.  Source rules are checked first in the person's
authentication DN entry, and if none of the {{EX:authzTo}} rules
specify the authorization is permitted, the {{EX:authzFrom}}
rules in the authorization DN entry are then checked. If neither
case specifies that the request be honored, the request is denied.
Since the default behaviour is to deny authorization requests, rules
only specify that a request be allowed; there are no negative rules
telling what authorizations to deny.

The value(s) in the two attributes are of the same form as the
output of the replacement pattern of a {{EX:authz-regexp}} directive:
either a DN or an LDAP URL. For example, if a {{EX:authzTo}}
value is a DN, that DN is one the authenticated user can authorize
to. On the other hand, if the {{EX:authzTo}} value is an LDAP
URL, the URL is used as an internal search of the LDAP database,
and the authenticated user can become ANY DN returned by the search.
If an LDAP entry looked like:

>	dn: cn=WebUpdate,dc=example,dc=com
>	authzTo: ldap:///dc=example,dc=com??sub?(objectclass=person)

then any user who authenticated as {{EX:cn=WebUpdate,dc=example,dc=com}}
could authorize to any other LDAP entry under the search base
{{EX:dc=example,dc=com}} which has an objectClass of {{EX:Person}}.


H4: Notes on Proxy Authorization Rules

An LDAP URL in a {{EX:authzTo}} or {{EX:authzFrom}} attribute
will return a set of DNs.  Each DN returned will be checked.  Searches
which return a large set can cause the authorization process to
take an uncomfortably long time. Also, searches should be performed
on attributes that have been indexed by slapd.

To help produce more sweeping rules for {{EX:authzFrom}} and
{{EX:authzTo}}, the values of these attributes are allowed to
be DNs with regular expression characters in them. This means a
source rule like

>	authzTo: uid=[^,]*,dc=example,dc=com

would allow that authenticated user to authorize to any DN that
matches the regular expression pattern given. This regular expression
comparison can be evaluated much faster than an LDAP search for
{{EX:(uid=*)}}.

Also note that the values in an authorization rule must be one of
the two forms: an LDAP URL or a DN (with or without regular expression
characters). Anything that does not begin with "{{EX:ldap://}}" is
taken as a DN. It is not permissable to enter another authorization
identity of the form "{{EX:u:<username>}}" as an authorization rule.


H4: Policy Configuration

The decision of which type of rules to use, {{EX:authzFrom}}
or {{EX:authzTo}}, will depend on the site's 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 who
should be allowed to perform the proxy authorization.

By default, processing of proxy authorization rules is disabled.
The {{EX:authz-policy}} directive must be set in the
{{slapd.conf}}(5) file to enable authorization. This directive can
be set to {{EX:none}} for no rules (the default), {{EX:to}} for
source rules, {{EX:from}} for destination rules, or {{EX:both}} for
both source and destination rules.

Destination rules are extremely powerful. If ordinary users have
access to write the {{EX:authzTo}} attribute in their own
entries, then they can write rules that would allow them to authorize
as anyone else.  As such, when using destination rules, the
{{EX:authzTo}} attribute should be protected with an ACL that
only allows privileged users to set its values.