keystone.identity.backends.ldap.common module¶
- class keystone.identity.backends.ldap.common.AsynchronousMessage(message_id, connection, context_manager)[source]¶
Bases:
objectA container for handling asynchronous LDAP responses.
Some LDAP APIs, like search_ext, are asynchronous and return a message ID when the server successfully initiates the operation. Clients can use this message ID and the original connection to make the request to fetch the results using result3.
This object holds the message ID, the original connection, and a callable weak reference Finalizer that cleans up context managers specific to the connection associated to the message ID.
- Parameters:
message_id – The message identifier (str).
connection – The connection associated with the message identifier (ldappool.StateConnector).
The clean attribute is a callable that cleans up the context manager used to create or return the connection object (weakref.finalize).
- class keystone.identity.backends.ldap.common.BaseLdap(conf)[source]¶
Bases:
object- DEFAULT_EXTRA_ATTR_MAPPING = []¶
- DEFAULT_FILTER = None¶
- DEFAULT_ID_ATTR = 'cn'¶
- DEFAULT_OBJECTCLASS = None¶
- DEFAULT_OU = None¶
- DEFAULT_STRUCTURAL_CLASSES = None¶
- NotFound = None¶
- add_member(member_dn, member_list_dn)[source]¶
Add member to the member list.
- Parameters:
member_dn – DN of member to be added.
member_list_dn – DN of group to which the member will be added.
- Raises:
keystone.exception.Conflict – If the user was already a member.
self.NotFound – If the group entry didn’t exist.
- attribute_ignore = []¶
- attribute_options_names = {}¶
- filter_query(hints, query=None)[source]¶
Apply filtering to a query.
- Parameters:
hints – contains the list of filters, which may be None, indicating that there are no filters to be applied. If it’s not None, then any filters satisfied here will be removed so that the caller will know if any filters remain to be applied.
query – LDAP query into which to include filters
- Returns query:
LDAP query, updated with any filters satisfied
- immutable_attrs = []¶
- model = None¶
- notfound_arg = None¶
- options_name = None¶
- tree_dn = None¶
- class keystone.identity.backends.ldap.common.EnabledEmuMixIn(conf)[source]¶
Bases:
BaseLdapEmulates boolean ‘enabled’ attribute if turned on.
Creates a group holding all enabled objects of this class, all missing objects are considered disabled.
Options:
$name_enabled_emulation - boolean, on/off
$name_enabled_emulation_dn - DN of that group, default is cn=enabled_${name}s,${tree_dn}
$name_enabled_emulation_use_group_config - boolean, on/off
Where ${name}s is the plural of self.options_name (‘users’ or ‘tenants’), ${tree_dn} is self.tree_dn.
- DEFAULT_GROUP_MEMBERS_ARE_IDS = False¶
- DEFAULT_GROUP_OBJECTCLASS = 'groupOfNames'¶
- DEFAULT_MEMBER_ATTRIBUTE = 'member'¶
- class keystone.identity.backends.ldap.common.KeystoneLDAPHandler(conn=None)[source]¶
Bases:
LDAPHandlerConvert data types and perform logging.
This LDAP interface wraps the python-ldap based interfaces. The python-ldap interfaces require string values encoded in UTF-8 with the exception of [1]. The OpenStack logging framework at the time of this writing is not capable of accepting strings encoded in UTF-8, the log functions will throw decoding errors if a non-ascii character appears in a string.
[1] In python-ldap, some fields (DNs, RDNs, attribute names, queries) are represented as text (str on Python 3, unicode on Python 2 when bytes_mode=False). For more details see: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode
Prior to the call Python data types are converted to a string representation as required by the LDAP APIs.
Then logging is performed so we can track what is being sent/received from LDAP. Also the logging filters security sensitive items (i.e. passwords).
Then the string values are encoded into UTF-8.
Then the LDAP API entry point is invoked.
Data returned from the LDAP call is converted back from UTF-8 encoded strings into the Python data type used internally in OpenStack.
- connect(url, page_size=0, alias_dereferencing=None, use_tls=False, tls_cacertfile=None, tls_cacertdir=None, tls_req_cert=2, chase_referrals=None, debug_level=None, conn_timeout=None, use_pool=None, pool_size=None, pool_retry_max=None, pool_retry_delay=None, pool_conn_timeout=None, pool_conn_lifetime=None)[source]¶
- class keystone.identity.backends.ldap.common.LDAPHandler(conn=None)[source]¶
Bases:
objectAbstract class which defines methods for a LDAP API provider.
Native Keystone values cannot be passed directly into and from the python-ldap API. Type conversion must occur at the LDAP API boundary, examples of type conversions are:
booleans map to the strings ‘TRUE’ and ‘FALSE’
integer values map to their string representation.
unicode strings are encoded in UTF-8
Note, in python-ldap some fields (DNs, RDNs, attribute names, queries) are represented as text (str on Python 3, unicode on Python 2 when bytes_mode=False). For more details see: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode
In addition to handling type conversions at the API boundary we have the requirement to support more than one LDAP API provider. Currently we have:
python-ldap, this is the standard LDAP API for Python, it requires access to a live LDAP server.
Fake LDAP which emulates python-ldap. This is used for testing without requiring a live LDAP server.
To support these requirements we need a layer that performs type conversions and then calls another LDAP API which is configurable (e.g. either python-ldap or the fake emulation).
We have an additional constraint at the time of this writing due to limitations in the logging module. The logging module is not capable of accepting UTF-8 encoded strings, it will throw an encoding exception. Therefore all logging MUST be performed prior to UTF-8 conversion. This means no logging can be performed in the ldap APIs that implement the python-ldap API because those APIs are defined to accept only UTF-8 strings. Thus the layer which performs type conversions must also do the logging. We do the type conversions in two steps, once to convert all Python types to unicode strings, then log, then convert the unicode strings to UTF-8.
There are a variety of ways one could accomplish this, we elect to use a chaining technique whereby instances of this class simply call the next member in the chain via the “conn” attribute. The chain is constructed by passing in an existing instance of this class as the conn attribute when the class is instantiated.
Here is a brief explanation of why other possible approaches were not used:
subclassing
To perform the wrapping operations in the correct order the type conversion class would have to subclass each of the API providers. This is awkward, doubles the number of classes, and does not scale well. It requires the type conversion class to be aware of all possible API providers.
decorators
Decorators provide an elegant solution to wrap methods and would be an ideal way to perform type conversions before calling the wrapped function and then converting the values returned from the wrapped function. However decorators need to be aware of the method signature, it has to know what input parameters need conversion and how to convert the result. For an API like python-ldap which has a large number of different method signatures it would require a large number of specialized decorators. Experience has shown it’s very easy to apply the wrong decorator due to the inherent complexity and tendency to cut-n-paste code. Another option is to parameterize the decorator to make it “smart”. Experience has shown such decorators become insanely complicated and difficult to understand and debug. Also decorators tend to hide what’s really going on when a method is called, the operations being performed are not visible when looking at the implemation of a decorated method, this too experience has shown leads to mistakes.
Chaining simplifies both wrapping to perform type conversion as well as the substitution of alternative API providers. One simply creates a new instance of the API interface and insert it at the front of the chain. Type conversions are explicit and obvious.
If a new method needs to be added to the API interface one adds it to the abstract class definition. Should one miss adding the new method to any derivations of the abstract class the code will fail to load and run making it impossible to forget updating all the derived classes.
- abstract connect(url, page_size=0, alias_dereferencing=None, use_tls=False, tls_cacertfile=None, tls_cacertdir=None, tls_req_cert=2, chase_referrals=None, debug_level=None, conn_timeout=None, use_pool=None, pool_size=None, pool_retry_max=None, pool_retry_delay=None, pool_conn_timeout=None, pool_conn_lifetime=None)[source]¶
- class keystone.identity.backends.ldap.common.PooledLDAPHandler(conn=None, use_auth_pool=False)[source]¶
Bases:
LDAPHandlerLDAPHandler implementation which uses pooled connection manager.
Pool specific configuration is defined in [ldap] section. All other LDAP configuration is still used from [ldap] section
Keystone LDAP authentication logic authenticates an end user using its DN and password via LDAP bind to establish supplied password is correct. This can fill up the pool quickly (as pool re-uses existing connection based on its bind data) and would not leave space in pool for connection re-use for other LDAP operations. Now a separate pool can be established for those requests when related flag ‘use_auth_pool’ is enabled. That pool can have its own size and connection lifetime. Other pool attributes are shared between those pools. If ‘use_pool’ is disabled, then ‘use_auth_pool’ does not matter. If ‘use_auth_pool’ is not enabled, then connection pooling is not used for those LDAP operations.
Note, the python-ldap API requires all string attribute values to be UTF-8 encoded. The KeystoneLDAPHandler enforces this prior to invoking the methods in this class.
Note, in python-ldap some fields (DNs, RDNs, attribute names, queries) are represented as text (str on Python 3, unicode on Python 2 when bytes_mode=False). For more details see: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode
- Connector¶
alias of
StateConnector
- auth_pool_prefix = 'auth_pool_'¶
- connect(url, page_size=0, alias_dereferencing=None, use_tls=False, tls_cacertfile=None, tls_cacertdir=None, tls_req_cert=2, chase_referrals=None, debug_level=None, conn_timeout=None, use_pool=None, pool_size=None, pool_retry_max=None, pool_retry_delay=None, pool_conn_timeout=None, pool_conn_lifetime=None)[source]¶
- connection_pools = {}¶
- result3(message, all=1, timeout=None, resp_ctrl_classes=None)[source]¶
Wait for and return the result to an asynchronous message.
This method returns the result of an operation previously initiated by one of the LDAP asynchronous operation routines (e.g., search_ext()). The search_ext() method in python-ldap returns an invocation identifier, or a message ID, upon successful initiation of the operation by the LDAP server.
The message is expected to be instance of class AsynchronousMessage, which contains the message ID and the connection used to make the original request.
The connection and context manager associated with search_ext() are cleaned up when message.clean() is called.
- search_ext(base, scope, filterstr='(objectClass=*)', attrlist=None, attrsonly=0, serverctrls=None, clientctrls=None, timeout=-1, sizelimit=0)[source]¶
Return an AsynchronousMessage instance, it asynchronous API.
The AsynchronousMessage instance can be safely used in a call to result3().
To work with result3() API in predictable manner, the same LDAP connection is needed which originally provided the msgid. So, this method wraps the existing connection and msgid in a new AsynchronousMessage instance. The connection associated with search_ext() is released after result3() fetches the data associated with msgid.
- class keystone.identity.backends.ldap.common.PythonLDAPHandler(conn=None)[source]¶
Bases:
LDAPHandlerLDAPHandler implementation which calls the python-ldap API.
Note, the python-ldap API requires all string attribute values to be UTF-8 encoded.
Note, in python-ldap some fields (DNs, RDNs, attribute names, queries) are represented as text (str on Python 3, unicode on Python 2 when bytes_mode=False). For more details see: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode
The KeystoneLDAPHandler enforces this prior to invoking the methods in this class.
- connect(url, page_size=0, alias_dereferencing=None, use_tls=False, tls_cacertfile=None, tls_cacertdir=None, tls_req_cert=2, chase_referrals=None, debug_level=None, conn_timeout=None, use_pool=None, pool_size=None, pool_retry_max=None, pool_retry_delay=None, pool_conn_timeout=None, pool_conn_lifetime=None)[source]¶
- keystone.identity.backends.ldap.common.convert_ldap_result(ldap_result)[source]¶
Convert LDAP search result to Python types used by OpenStack.
Each result tuple is of the form (dn, attrs), where dn is a string containing the DN (distinguished name) of the entry, and attrs is a dictionary containing the attributes associated with the entry. The keys of attrs are strings, and the associated values are lists of strings.
OpenStack wants to use Python types of its choosing. Strings will be unicode, truth values boolean, whole numbers int’s, etc. DN’s are represented as text in python-ldap by default for Python 3 and when bytes_mode=False for Python 2, and therefore do not require decoding.
- Parameters:
ldap_result – LDAP search result
- Returns:
list of 2-tuples containing (dn, attrs) where dn is unicode and attrs is a dict whose values are type converted to OpenStack preferred types.
- keystone.identity.backends.ldap.common.dn_startswith(descendant_dn, dn)[source]¶
Return True if and only if the descendant_dn is under the dn.
- Parameters:
descendant_dn – Either a string DN or a DN parsed by ldap.dn.str2dn.
dn – Either a string DN or a DN parsed by ldap.dn.str2dn.
- keystone.identity.backends.ldap.common.enabled2py(val)[source]¶
Similar to ldap2py, only useful for the enabled attribute.
- keystone.identity.backends.ldap.common.filter_entity(entity_ref)[source]¶
Filter out private items in an entity dict.
- Parameters:
entity_ref – the entity dictionary. The ‘dn’ field will be removed. ‘dn’ is used in LDAP, but should not be returned to the user. This value may be modified.
- Returns:
entity_ref
- keystone.identity.backends.ldap.common.is_ava_value_equal(attribute_type, val1, val2)[source]¶
Return True if and only if the AVAs are equal.
When comparing AVAs, the equality matching rule for the attribute type should be taken into consideration. For simplicity, this implementation does a case-insensitive comparison.
Note that this function uses prep_case_insenstive so the limitations of that function apply here.
- keystone.identity.backends.ldap.common.is_dn_equal(dn1, dn2)[source]¶
Return True if and only if the DNs are equal.
Two DNs are equal if they’ve got the same number of RDNs and if the RDNs are the same at each position. See RFC4517.
Note that this function uses is_rdn_equal to compare RDNs so the limitations of that function apply here.
- Parameters:
dn1 – Either a string DN or a DN parsed by ldap.dn.str2dn.
dn2 – Either a string DN or a DN parsed by ldap.dn.str2dn.
- keystone.identity.backends.ldap.common.is_rdn_equal(rdn1, rdn2)[source]¶
Return True if and only if the RDNs are equal.
RDNs must have the same number of AVAs.
Each AVA of the RDNs must be the equal for the same attribute type. The order isn’t significant. Note that an attribute type will only be in one AVA in an RDN, otherwise the DN wouldn’t be valid.
Attribute types aren’t case sensitive. Note that attribute type comparison is more complicated than implemented. This function only compares case-insentive. The code should handle multiple names for an attribute type (e.g., cn, commonName, and 2.5.4.3 are the same).
Note that this function uses is_ava_value_equal to compare AVAs so the limitations of that function apply here.
- keystone.identity.backends.ldap.common.ldap2py(val)[source]¶
Convert an LDAP formatted value to Python type used by OpenStack.
Virtually all LDAP values are stored as UTF-8 encoded strings. OpenStack prefers values which are unicode friendly.
- Parameters:
val – LDAP formatted value
- Returns:
val converted to preferred Python type
- keystone.identity.backends.ldap.common.prep_case_insensitive(value)[source]¶
Prepare a string for case-insensitive comparison.
This is defined in RFC4518. For simplicity, all this function does is lowercase all the characters, strip leading and trailing whitespace, and compress sequences of spaces to a single space.
- keystone.identity.backends.ldap.common.py2ldap(val)[source]¶
Type convert a Python value to a type accepted by LDAP (unicode).
The LDAP API only accepts strings for values therefore convert the value’s type to a unicode string. A subsequent type conversion will encode the unicode as UTF-8 as required by the python-ldap API, but for now we just want a string representation of the value.
- Parameters:
val – The value to convert to a LDAP string representation
- Returns:
unicode string representation of value.
- keystone.identity.backends.ldap.common.use_conn_pool(func)[source]¶
Use this only for connection pool specific ldap API.
This adds connection object to decorated API as next argument after self.
- keystone.identity.backends.ldap.common.utf8_decode(value)[source]¶
Decode a from UTF-8 into unicode.
If the value is a binary string assume it’s UTF-8 encoded and decode it into a unicode string. Otherwise convert the value from its type into a unicode string.
- Parameters:
value – value to be returned as unicode
- Returns:
value as unicode
- Raises:
UnicodeDecodeError – for invalid UTF-8 encoding
- keystone.identity.backends.ldap.common.utf8_encode(value)[source]¶
Encode a basestring to UTF-8.
If the string is unicode encode it to UTF-8, if the string is str then assume it’s already encoded. Otherwise raise a TypeError.
- Parameters:
value – A basestring
- Returns:
UTF-8 encoded version of value
- Raises:
TypeError – If value is not basestring
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.