Group Support Planning
I’ve been doing some thinking on how to best implement group support into the plugin. This would probably be a multi phase approach, to hopefully fulfill all requests.
NOTE: This is currently a work in progress and there is no estimate on when it will be complete
Per Blog Settings
LDAP Group mapping on a per blog, per role basis. This would all for any given blog to map each individual role to a separate LDAP group. The goal would be for these groups to automatically check for new users on logon and update accordingly. The biggest concern here is figuring out a way for the automatic updating to happen without having a huge impact on performance.
Sitewide Settings
Group based control of the following:
- Who can login to the blog (standard user)
- Who can login to the blog with automatic blog creation
- Who can’t login – deny list
Are there any other thoughts on other possible setups or anything else that others would like added? If so – please leave a comment with your thoughts!
Why not an attribute on the user entry in LDAP rather than a group?
Although I do not know anything about your architecture, Perhaps something on the user like:
Attribute Name: Attribute Value
blogLoginDN: cn=blog1
blogCreate cn=blog2
For denied, why not attributes on the blog entry:
Attribute Name: Attribute Value:
deny uid=jwilleke,ou=users,dc=somewhere,dc=com
Generally, Groups are bad from a performance standpoint.
Just my two cents.
-jim
This sounds good.
I don’t know much about LDAP Groups but what I think might be really useful for us is to be able to automatically add new users to certain blogs (and maybe even BuddyPress groups) depending on their LDAP Group.
I understand the “Automatic Updating” as a kind of synchronisation feature (is that what you mean?); it would be really cool if WordPress could automatically synchronise itself with the LDAP user groups (and automatically add new users to groups and also remove old users).
Technically the WordPress Cron might be a good place to put the automatic synchronisation bit (see function wp_schedule_event()), and of course the state for a user would also have to be “checked” whenever a user logs in. WP_Cron is build so it does not affect frontend performance directly (as long as the server can cope) and is e.g. used for the twice-daily update checks at the moment.
@Jim Willeke
For alot of people (myself included) it’s not going to be practical to add attributes to the ldap server for such things. Are you interested in this functionality?
@Ben Forchhammer
My goal is to have any updating happen on user login – i’ll probably stay away from wp_cron for this.
hello,
these features are already working?
No – these are not working yet
any progress on this yet ?
One reason to hook roles to LDAP attributes is that one might want to be able to control access based on something like a department name. In our LDAP directory things like departments and user types (i.e. faculty/staff/student) are stored as attributes, not groups.
We absolutely need this. Drupal has it, by the way, in the “LDAP Integration module” http://drupal.org/project/ldap_integration which is in PHP and is open source, if you wanted to investigate the code.