fabacab / wp-ldap

:busts_in_silhouette::office: Manage your LDAP DIT using your WordPress Dashboard.

WP-LDAP

WP-LDAP is a feature-rich LDAPv3 connector for WordPress that turns your WordPress Multisite Network into a front-end for managing an LDAP Directory Information Tree (DIT). It automates the process of managing user account information to support single sign-on ("SSO"), identity management, and other enterprise functions through the familiar WordPress Network Admin Dashboard screens.

See the readme.txt file for a longer description.

This plugin is designed for medium to large deployments of WordPress Multisite (or Multi-Network) instances, originally developed as a collaboration with the Glocal Coop's Activist Network Platform project. If you run multiple WordPress Multisite Networks, you can configure each WP Network with different LDAP settings. This plugin does not currently support single-site installs; please post an issue on GitHub if you want to use LDAP data stores with a WP single-site install and we can discuss use cases.

Developing

The easiest way to develop is to use VVV's Custom Site Template setup. Once that's installed and you have a running WP Multisite, perform the following additional commands:

vagrant ssh                          # Enter the Vagrant VM.
sudo apt install -y php-ldap         # Install the PHP LDAP extension for your default PHP version.
sudo apt install -y slapd ldap-utils # Install OpenLDAP's stand-alone LDAP daemon and helper utilities.
# sudo dpkg-reconfigure slapd        # Reconfigure to add a basic DIT, if not automatically triggered.

Please see the project wiki for additional information.

wp-ldap's Issues

Risk of account hijacking if a Super Admin deletes a user account from the database.

It is possible to hijack a user's account by registering the same username as one that has been deleted by a Super Admin. Imagine the following scenario:

1. A user registers as "UserA" (and is given an ID number of 2).
2. Sometime in the future, a Super Admin deletes this user from WP; this user's record now only exists in the LDAP DIT, but not the WordPress database.
3. Afterwards, a distinct human registers another account called "UserA" (but is given an ID number of 3).

The second human to register the same username ("UserA") is now in control over any SSO-linked accounts using the given username because those other applications (Nextcloud, for instance), will be searching the LDAP DIT and will find a matching record. As password resets are sync'ed from the WordPress DB to the LDAP DIT, this second registration effectively re-sets the account password as well, obviating the need to crack the original user's password hash.

This situation arises only if a Super Admin manually removes the WordPress user record from WordPress's database, as otherwise WordPress will not permit a registration using the existing username, but this isn't that far-fetched of a possibility.

One clear mitigation is to embed the auto-incrementing user ID that the MySQL database generates as part of the wp_users table into the LDAP DN, so that when (3) happens in the timeline above, the LDAP entity associated with this second human's registration will be distinct from the first human's registration, despite both users having the same uid value in the LDAP DIT (i.e., user_login on the WordPress side).

Deletion

The LDAP entry should be deleted when the WP user is deleted.

When updating already-existing users who do not have LDAP DIT entries causes PHP Warning

PHP Warning:  ldap_modify(): Modify: No such object in [WORDPRESS_ROOT]/wp-content/plugins/wp-ldap/includes/class-wp-ldap-api.php on line 189                                                        
Warning: ldap_modify(): Modify: No such object in [WORDPRESS_ROOT]/wp-content/plugins/wp-ldap/includes/class-wp-ldap-api.php on line 189

Server Config Documentation

I'd like to outline what needs to get done to install what's needed on the server. In the case we use Debian with Apache. Maybe we can work together on this?

profile_update

If a user was created before wp-ldap is activated, the user is never update because it was never created in ldap.

profile_update should create the missing LDAP entry.

Please find the updated code

        $sb = self::getSearchBaseDN();
        $LDAP->setBaseDN( $sb );
        $search_results = $LDAP->search(
            '(&(objectClass=inetOrgPerson)(uid=' . API::escape_filter( $WP_User->user_login ) . '))'
        );

        if ( 1 > count( $search_results ) ) {
            $LDAP_User = new \WP_LDAP\User();
            $LDAP_User->setWordPressUser( get_userdata( $user_id ) );
            $LDAP->add(
                $LDAP_User->getEntityDN( $sb ),
                apply_filters( self::prefix . 'user_to_entity' , $LDAP_User->wp2entity() )
            );
        } else {
            $LDAP->modify(
                $LDAP_User->getEntityDN( $sb ),
                apply_filters( self::prefix . 'user_to_entity', $LDAP_User->wp2entity() )
            );
        }

Groups across apps some use cases

As of now, I believe that a user that is created in WordPress can/will create a user on NextCloud, probably can work with Piwik too. However that is an individual account without specific access to anything that may be shared. Maybe we can outline some use cases to plan for.

Since we are working with a WordPress multisite, and in some cases multinetwork, users may be administrators or editors of one or multiple website. Maybe there's a way to define this and say if xyz role also add access to a group in NextCloud and can view that sites analytics in Piwik, for example. However, subscribers would just be a user across applications with no additional group associations.

Looking at NextCloud specifically users management also has groups, how can we tie into this? Initial thought is Site Admin is Admin of a group of that site and editors maybe users with access.

What's the best way to outline this?