X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=doc%2Fguide%2Fadmin%2Fsasl.sdf;h=9f8a7a66cd3eb0a12b66294dc34a5e98997078b2;hb=f9e417a2634a6681941772ed488ffaff47f33a4c;hp=9651a0bcfc3738c08cb01bb96456c2e9ec979c47;hpb=c3998fb2101d63df1aef446c44858cea72e915a1;p=openldap diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf index 9651a0bcfc..9f8a7a66cd 100644 --- a/doc/guide/admin/sasl.sdf +++ b/doc/guide/admin/sasl.sdf @@ -1,4 +1,5 @@ -# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved. +# $OpenLDAP$ +# Copyright 1999-2013 The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. H1: Using SASL @@ -71,10 +72,13 @@ and large enterprises. Use of {{SECT:GSSAPI}} and {{SECT:KERBEROS_V4}} are discussed below. The EXTERNAL mechanism utilizes authentication services provided -by lower level network services such as {{TERM:TLS}} (TLS). When +by lower level network services such as {{TERM[expand]TLS}} ({{TERM:TLS}}). When used in conjunction with {{TERM:TLS}} {{TERM:X.509}}-based public -key technology, EXTERNAL offers strong authentication. Use of -EXTERNAL is discussed in the {{SECT:Using TLS}} chapter. +key technology, EXTERNAL offers strong authentication. +TLS is discussed in the {{SECT:Using TLS}} chapter. + +EXTERNAL can also be used with the {{EX:ldapi:///}} transport, as +Unix-domain sockets can report the UID and GID of the client process. There are other strong authentication mechanisms to choose from, including {{TERM:OTP}} (one time passwords) and {{TERM:SRP}} (secure @@ -266,9 +270,9 @@ See {{SECT: Mapping Authentication Identities}} below for information on optional mapping of identities. With suitable mappings in place, users can specify SASL IDs when -performing LDAP operations and sldb}} and the directory itself will -be used to verify the authentication. For example, the user -identified by the directory entry: +performing LDAP operations, and the password stored in {{sasldb}} or in +the directory itself will be used to verify the authentication. +For example, the user identified by the directory entry: > dn: cn=Andrew Findlay+uid=u000997,dc=example,dc=com > objectclass: inetOrgPerson @@ -288,6 +292,41 @@ The server will infer an authorization identity from authentication identity (as described below). +H3: EXTERNAL + +The SASL EXTERNAL mechanism makes use of an authentication performed +by a lower-level protocol: usually {{TERM:TLS}} or Unix {{TERM:IPC}} + +Each transport protocol returns Authentication Identities in its own +format: + +H4: TLS Authentication Identity Format + +This is the Subject DN from the client-side certificate. +Note that DNs are displayed differently by LDAP and by X.509, so +a certificate issued to +> C=gb, O=The Example Organisation, CN=A Person + +will produce an authentication identity of: + +> cn=A Person,o=The Example Organisation,c=gb + +Note that you must set a suitable value for TLSVerifyClient to make the server +request the use of a client-side certificate. Without this, the SASL EXTERNAL +mechanism will not be offered. +Refer to the {{SECT:Using TLS}} chapter for details. + +H4: IPC (ldapi:///) Identity Format + +This is formed from the Unix UID and GID of the client process: + +> gidNumber=+uidNumber=,cn=peercred,cn=external,cn=auth + +Thus, a client process running as {{EX:root}} will be: + +> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth + + H3: Mapping Authentication Identities The authentication mechanism in the slapd server will use SASL @@ -352,7 +391,7 @@ 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 +The replacement pattern will produce either a DN or URL referring 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 @@ -542,7 +581,7 @@ 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}} +directly to the privileged account, possibly through the {{EX:rootpw}} {{slapd.conf}}(5) directive or through a {{EX:userPassword}} attribute, then auditing becomes more difficult. @@ -576,7 +615,7 @@ or In the first form, the 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. +it is referred 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 @@ -617,7 +656,7 @@ 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 +Since the default behavior is to deny authorization requests, rules only specify that a request be allowed; there are no negative rules telling what authorizations to deny. @@ -651,7 +690,7 @@ To help produce more sweeping rules for {{EX:authzFrom}} and be DNs with regular expression characters in them. This means a source rule like -> authzTo: uid=[^,]*,dc=example,dc=com +> authzTo: dn.regex:^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 @@ -661,7 +700,7 @@ comparison can be evaluated much faster than an LDAP search for 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 +taken as a DN. It is not permissible to enter another authorization identity of the form "{{EX:u:}}" as an authorization rule.