Without going into much detail about how the different system worked, I will quickly say that user permissions where granted to a user on another internal site, but this data could be queried via LDAP. Although from this point onward I'll be talking about LDAP authentication any other similar system could perform the same functionality that LDAP offers.
If you have created or worked with the WordPress API you would of encounter 'hooks', if you have not I suggest you read up on them. I will not be providing much actual code but it should be fairly easy to take the instructions/small snippets and write them into a class for your plugin.
- Create a plugin, unless your going to add to an existing plugin although personally I would advise against this for points I'll explain later.
- Remove the standard 'authenticate' function using remove_filter. remove_filter('authenticate', 'wp_authenticate_username_password', 20);
- Create your own function and add to the authenticate hook using add_filter, this function should take 3 parameters, a user, email and password. add_filter('authenticate', 'myAuthFunction', 30, 3);
- In the new function you just created you need to add your code. Normally once the user submits their email and password, the email is used to get the 'user' which is a wp class. This is checked against the local database to make sure the user/password is valid. Rather then doing this, as we don't want to keep a copy of users passwords locally on the server this site is being hosted on, I used a LDAP query which did the authentication for me and return if the user is valid or not.
- So now we have checked if the user is valid and has the permissions to log into the site, but I also said at the start we didn't want people to have to create a account to log in. One of the advantages of the LDAP query we just did is that we checked that the user was valid to enter the site and their authentication was correct (email/password). But to have a user on WordPress this needs to be held locally, so what we can now do is check with the wp_users table in the database to see if we have that users' account and if not we can automatically create a user account on the user first log in. wp_create_user requires a few things to create a user account one being a password (other things like email the user has already provided), so the trick here is to not store a password. When we pass the password string parameter into the function we use a blank string for the password.
- You might be thinking if everyone has a blank password doesn't that just make the site insecure? No it doesn't as the first check we do is with LDAP, if the user fails their log in here it returns false, so we don't even go to check the local WordPress users just instantly tell the user they failed to log in. If the LDAP query results true, then we can look up the password to check if it matches a blank password (which it will).
- User submits email and password on the login page
- Details checked against LDAP query
- If successfully authenticated from LDAP, check if that user has a user locally and if not create one
- Log that user in using the details from there locally stored user.
One last note the only user in the WordPress database that will have a password stored is the root, admin or any other name you used, user created when WordPress was installed. Although this user couldn't log in with the password set during the install while this plugin is active it will however be the only user that can log in if this plugin is disabled, this is why I said at the start you would want to have this as a separate plugin.