Make LDAP Group to Role mapping configurable via web interface

This is my first Drupal patch submission. Feedback is highly desirable.

Summary

Moved configuration for LDAP Group to Drupal role mapping from ldap_integration/ldapgroups.conf.php
to be configurable via Drupal web interface. This will allow per site configuration of LDAP group to
drupal role mappings.
Admins will now need to have LDAP group to Drupal role mappings for each site on a multisite install.
Admins will also need to have separate mappings for each LDAP instance within a site.

Screenshots: http://staff.ed.uiuc.edu/jbarclay/ldapgroups/

Not sure where the hook_update code fits into this version, but I added it and tested it.
The update will import group mappings in file ldap_integration/ldapgroups.conf.php into db configuration (if this file
is left in place and the ldapgroups_roles_filter function is not commented out.)

screenshots

http://staff.ed.uiuc.edu/jbarclay/ldapgroups/

File Change Summary

ldap_integration/ldapgroups.conf.php
- removed file. data now stored in db.

ldap_integration/LDAPInterface.php
- add 2 new properties: use_group_filter and role_mappings

ldapgroups.admin.inc
- added new fields to database reset and update operations.
- added new fields to admin form.
- added functions to validate and convert back and forth from | delimited text area to serialized array

ldapgroups.module
- remove require integration/ldapgroups.conf.php
- added new fields to init
- added function _ldapgroups_roles_filter to module. was in ldap_integration/ldapgroups.conf.php
- change logic in ldapgroups_user_login to use use_group_filter property to decide to use group filtering.

ldapgroups.install
- added ldapauth.ldapgroups_use_group_filter ldapauth.ldapgroups_role_mappings to unistall and install
- added hook_update to add db columns and import group mappings in file ldap_integration/ldapgroups.conf.php into db. User's will need to leave their
old ldap_integration/ldapgroups.conf.php file in place and comment out the _ldapgroups_roles_filter function, but not their
array in ldapgroups_role_mappings()

Tests

- install groups:
- make sure fields are created: ldapauth.ldapgroups_use_group_filter, ldapauth.ldapgroups_role_mappings
- if integration/ldapgroups.conf.php is present and has function uncommented and data, make sure data is imported
- uninstall ldap groups. make sure fields are removed.
- edit configuration. test validation.
- log in and out making sure roles are mapped correctly

I agree. I think both are doable and desirable. I'll resubmit when I'm done.

So all the group fields in ldapauth.ldapgroups_* should go in a separate interface and table, right?
- ldapauth.ldapgroups_* moves to ldapgroups.*

e.g.

ldapauth.ldapgroups_in_dn => ldapgroups.in_dn

There should be one record in the ldapgroups table for each ldapauth record with sid as the foreign key so that each ldap server can have its own group mappings? I think this is simplest since most people will only use one server and those who use 2, may have different mappings and group structures on each.

And move them to a separate db table (ldapgroups.*)

I ended up shifting much of the code in ldapgroups.module into a separate class to improve efficiency and readability. All the code was being required in the hook_init and ldapgroups.module regardless of it was being used. Not sure what performance effect this has but readability is improved.

I also changed the query to only remove user_roles records that were no longer granted from ldap, rather than removing them all and adding some or all of them back.

The other changes are those that I originally set out to do:

new db and form fields added to update, install, uninstall, and admin forms for configuring the 3 newly configurable fields:
1. LDAP Group to Drupal Roles Filtering on/off switch
2. Mapping of groups to drupal roles
3. php for filtering roles (defaults to current php).

Hope the efficiency and class additions are ok.

John

Let me clean the code up a bit and add some comments first. I've already fixed a bug also.

Since this is more of a rewrite, I added a couple of simple feature requests so the testing for all could be done at once:

- ability to use ldap groups without using ldap authentication.
* http://drupal.org/node/187990
* possibly related to webserver authentication: http://drupal.org/node/324732
- ability to limit who can create accounts based on ldap group membership
* http://drupal.org/node/322093

These required a little code in ldapauth.module file, but most of the code and all of the admin is in the ldapgroups files.

Attached is the tests I did and the patch.

Note this is a patch to the dev version:
RCS file: /cvs/drupal-contrib/contributions/modules/ldap_integration/ldapauth.module,v
retrieving revision 1.32.2.18
diff -u -p -r1.32.2.18 ldapauth.module
--- ldap_integration/ldapauth.module 5 Oct 2008 18:46:47 -0000 1.32.2.18

John Barclay

Heres the same patch as above (v3) with tweaks to meet Drupal coding conventions. I was travelling and read the coding conventions section of "Pro Drupal Development" and installed the coder module.

John

this patch is for the dev version of ldap groups. Its not current with the alpha and beta versions. I will bring it up to date, but if no one will test it its pointless. If 2 people will commit to testing it, I'll bring it up to date this weekend. John

Thanks stevestoker. Attached is the patch described above in 2, 7, and 10. It for alpha2. The patch in #11 is for the Oct 5th dev version. I will make a patch for the Oct 14th dev if need be.

I can't do a diff of a new file without modify rights to the repository; because I don't know how.

So I've added the missing file in #21.

These are the three urls:

/admin/settings/ldap/ldapgroups

/admin/settings/ldap/ldapgroups/edit/N , where N is the id of your ldap configuration, probably 1

/admin/settings/ldap/ldapgroups/woauth/edit (for using ldap groups without ldap authentication).

Do any of these urls function? Is it possible the menu is cached? May clear the cache at: /admin/settings/performance

What url is the bad link on? (The one that points to the adminisiter by module page)

thanks for testing. Not sure what the problem is. Line 144 is simply:

require_once(drupal_get_path('module', 'ldapgroups') .'/ldapgroupconf.class.php');

Perhaps a debugging line at 143 to see if the path is correct.

print drupal_get_path('module', 'ldapgroups') .'/ldapgroupconf.class.php'; die;

yep. I'll try to get to this today.

I can't do a diff of a new file without modify rights to the repository; because I don't know how. So the patch in #14 and the attached file placed in the top level ldap_integration folder should do the trick.

I'm also adding a zip of everything in case this doesn't do the trick. The .zip includes the ldap help module I'm working on.

thanks. I'll make those 2 changes.

The text in "Mapping of LDAP groups to Drupal Roles (one per line)" depends on which mappings you are using. This is why its confusing.

At /admin/settings/ldap/ldapgroups/edit/1 there are 3 cases, any mix of which can be used to figure out what "groups" a person belongs to. They aren't necessarily LDAP groups.

-----------------------------------------
Case 1: Group is specified in user's DN
Check this option if your users' DNs look like cn=jdoe,ou=Group1,cn=example,cn=com and Group1 turns out to be the group you want.

entry would look like:

Group1|Drupal Role
------------------------------------------
Case 2: Groups are specified by LDAP attributes

entry would look like whated the attribute value was. for example if the attribute name was "memberOf" in an Active Directory, the value would be like: cn=ED Staff,ou=education,DC=ad,DC=uiuc,DC=edu

and the entry would look like:
cn=ED Staff,ou=education,DC=ad,DC=uiuc,DC=edu|staff

-------------------------------------------
Case 3:

Groups exist as LDAP entries where a multivalued attribute contains the members' CNs

not sure about this one.

--------------------------------------------
at line 302 of ldapgroupconf.class, put the following code and login. It will show the syntax to use:

 print "<h2>dn_groups</h2><pre>"; print_r($dn_groups);
  print "<h2>attrib_groups</h2><pre>"; print_r($attrib_groups);
  print "<h2>entries_groups</h2><pre>"; print_r($entries_groups);
  print "</pre>";
  die;

if you get something like:

dn_groups

Array
(
    [0] => campus accounts
)
attrib_groups

Array
(
    [0] => CN=crb,OU=roles,OU=Portal,DC=ad,DC=uiuc,DC=edu

You should use a syntax like:

campus accounts|drupal role x
CN=crb,OU=roles,OU=Portal,DC=ad,DC=uiuc,DC=edu|drupal role 2

I hope to add this kind of ldap groups support in the help module, but need to get this patch into ldap groups.

John

Thanks very much for testing this. And your description is very helpful. I will work your description into the documentation.

Perhaps I can add to the ldap help module some code that generated mapping examples based on group configurations and your existing roles.

Thanks. I've been using this for some time and a handful of others have tried it out. I think its ready to go.

Should I patch this against head or another version?

It would be great to get this into the module. With hard coded group filters it not possible to use multisite configuration or do any of the newer drupal automation techniques such as:

- features, http://dc2009.drupalcon.org/session/paradigm-reusable-drupal-features
- implementing patterns module, http://drupal.org/project/patterns
- implementing install profiles
- ctools, http://drupal.org/project/ctools

I can make it non oop no problem. If I do will it make this release? ...Its a little late to mention that oop may not be appropriate since we've already had people testing it. You mention in #8 to have some people install and test it and I've been working on getting that to happen.

If it won't can we package them separately so the complementary module's progress isn't so slow and more maintainers can participate? I use the ldap groups module in many of my sites and I need it to support multisite installs.

Great. Let me know if I can help in coverting it or testing.

Aside from making the content configurable via the web, the other feature in this code is making ldap groups usable without ldap auth. In fact in would be nice to simply turn ldap auth off without turning the module off (no hook_user, hook_init, and hook user validate) and still have access to the ldap servers and functions. Like a loose api.

I should say using the ldapauth functionality of configuring one or more ldap servers; but not using the functionality of authentication when a user logs on.

This allows other functionality to be built on top of the ldapauth when its not being used to log a user on.

We use a service account to bind to LDAP. Some people call it a machine account. Its a single LDAP account that has the lowest level permissions possible for the task at hand.

It the ldap interface: /admin/settings/ldapauth/edit/1 in the field "DN for non-anonymous search: "