mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
39adb6d3a8
We use convenience types (classes) in IPA which make working with LDAP easier and more robust. It would be really nice if the basic python-ldap library understood our utility types and could accept them as parameters to the basic ldap functions and/or the basic ldap functions returned our utility types. Normally such a requirement would trivially be handled in an object- oriented language (which Python is) by subclassing to extend and modify the functionality. For some reason we didn't do this with the python-ldap classes. python-ldap objects are primarily used in two different places in our code, ipaserver.ipaldap.py for the IPAdmin class and in ipaserver/plugins/ldap2.py for the ldap2 class's .conn member. In IPAdmin we use a IPA utility class called Entry to make it easier to use the results returned by LDAP. The IPAdmin class is derived from python-ldap.SimpleLDAPObject. But for some reason when we added the support for the use of the Entry class in SimpleLDAPObject we didn't subclass SimpleLDAPObject and extend it for use with the Entry class as would be the normal expected methodology in an object-oriented language, rather we used an obscure feature of the Python language to override all methods of the SimpleLDAPObject class by wrapping those class methods in another function call. The reason why this isn't a good approach is: * It violates object-oriented methodology. * Other classes cannot be derived and inherit the customization (because the method wrapping occurs in a class instance, not within the class type). * It's non-obvious and obscure * It's inefficient. Here is a summary of what the code was doing: It iterated over every member of the SimpleLDAPObject class and if it was callable it wrapped the method. The wrapper function tested the name of the method being wrapped, if it was one of a handful of methods we wanted to customize we modified a parameter and called the original method. If the method wasn't of interest to use we still wrapped the method. It was inefficient because every non-customized method (the majority) executed a function call for the wrapper, the wrapper during run-time used logic to determine if the method was being overridden and then called the original method. So every call to ldap was doing extra function calls and logic processing which for the majority of cases produced nothing useful (and was non-obvious from brief code reading some methods were being overridden). Object-orientated languages have support built in for calling the right method for a given class object that do not involve extra function call overhead to realize customized class behaviour. Also when programmers look for customized class behaviour they look for derived classes. They might also want to utilize the customized class as the base class for their use. Also the wrapper logic was fragile, it did things like: if the method name begins with "add" I'll unconditionally modify the first and second argument. It would be some much cleaner if the "add", "add_s", etc. methods were overridden in a subclass where the logic could be seen and where it would apply to only the explicit functions and parameters being overridden. Also we would really benefit if there were classes which could be used as a base class which had specific ldap customization. At the moment our ldap customization needs are: 1) Support DN objects being passed to ldap operations 2) Support Entry & Entity objects being passed into and returned from ldap operations. We want to subclass the ldap SimpleLDAPObject class, that is the base ldap class with all the ldap methods we're using. IPASimpleLDAPObject class would subclass SimpleLDAPObject class which knows about DN objects (and possilby other IPA specific types that are universally used in IPA). Then IPAEntrySimpleLDAPObject would subclass IPASimpleLDAPObject which knows about Entry objects. The reason for the suggested class hierarchy is because DN objects will be used whenever we talk to LDAP (in the future we may want to add other IPA specific classes which will always be used). We don't add Entry support to the the IPASimpleLDAPObject class because Entry objects are (currently) only used in IPAdmin. What this patch does is: * Introduce IPASimpleLDAPObject derived from SimpleLDAPObject. IPASimpleLDAPObject is DN object aware. * Introduce IPAEntryLDAPObject derived from IPASimpleLDAPObject. IPAEntryLDAPObject is Entry object aware. * Derive IPAdmin from IPAEntryLDAPObject and remove the funky method wrapping from IPAdmin. * Code which called add_s() with an Entry or Entity object now calls addEntry(). addEntry() always existed, it just wasn't always used. add_s() had been modified to accept Entry or Entity object (why didn't we just call addEntry()?). The add*() ldap routine in IPAEntryLDAPObject have been subclassed to accept Entry and Entity objects, but that should proably be removed in the future and just use addEntry(). * Replace the call to ldap.initialize() in ldap2.create_connection() with a class constructor for IPASimpleLDAPObject. The ldap.initialize() is a convenience function in python-ldap, but it always returns a SimpleLDAPObject created via the SimpleLDAPObject constructor, thus ldap.initialize() did not allow subclassing, yet has no particular ease-of-use advantage thus we better off using the obvious class constructor mechanism. * Fix the use of _handle_errors(), it's not necessary to construct an empty dict to pass to it. If we follow the standard class derivation pattern for ldap we can make us of our own ldap utilities in a far easier, cleaner and more efficient manner. |
||
|---|---|---|
| .tx | ||
| checks | ||
| contrib | ||
| daemons | ||
| doc | ||
| init | ||
| install | ||
| ipa-client | ||
| ipalib | ||
| ipapython | ||
| ipaserver | ||
| selinux | ||
| tests | ||
| util | ||
| .bzrignore | ||
| .gitignore | ||
| API.txt | ||
| autogen.sh | ||
| BUILD.txt | ||
| Contributors.txt | ||
| COPYING | ||
| freeipa.spec.in | ||
| ipa | ||
| ipa-compliance.cron | ||
| ipa.1 | ||
| lite-server.py | ||
| make-doc | ||
| make-lint | ||
| make-test | ||
| make-testcert | ||
| makeapi | ||
| Makefile | ||
| MANIFEST.in | ||
| README | ||
| setup-client.py | ||
| setup.py | ||
| TODO | ||
| VERSION | ||
| version.m4.in | ||
IPA Server
What is it?
-----------
For efficiency, compliance and risk mitigation, organizations need to
centrally manage and correlate vital security information including:
* Identity (machine, user, virtual machines, groups, authentication
credentials)
* Policy (configuration settings, access control information)
* Audit (events, logs, analysis thereof)
Since these are not new problems. there exist many approaches and
products focused on addressing them. However, these tend to have the
following weaknesses:
* Focus on solving identity management across the enterprise has meant
less focus on policy and audit.
* Vendor focus on Web identity management problems has meant less well
developed solutions for central management of the Linux and Unix
world's vital security info. Organizations are forced to maintain
a hodgepodge of internal and proprietary solutions at high TCO.
* Proprietary security products don't easily provide access to the
vital security information they collect or manage. This makes it
difficult to synchronize and analyze effectively.
The Latest Version
------------------
Details of the latest version can be found on the IPA server project
page under <http://www.freeipa.org/>.
Documentation
-------------
The most up-to-date documentation can be found at
<http://freeipa.org/page/Documentation/>.
Quick Start
-----------
To get started quickly, start here:
<https://fedorahosted.org/freeipa/wiki/QuickStartGuide>
Licensing
---------
Please see the file called COPYING.
Contacts
--------
* If you want to be informed about new code releases, bug fixes,
security fixes, general news and information about the IPA server
subscribe to the freeipa-announce mailing list at
<https://www.redhat.com/mailman/listinfo/freeipa-interest/>.
* If you have a bug report please submit it at:
<https://bugzilla.redhat.com>
* If you want to participate in actively developing IPA please
subscribe to the freeipa-devel mailing list at
<https://www.redhat.com/mailman/listinfo/freeipa-devel/> or join
us in IRC at irc://irc.freenode.net/freeipa