Switch user permissions to subscriber when user deleted from AD

[blobaugh]

Users deleted from an AD group currently potentially still have access to WordPress via the lost password form. This could, for instance, allow an admin who is no longer with an organization to regain admin access to the website.

When user login fails AAD does not report back about the user, only that login has failed, thus there is no easy way to determine the user has been removed.

Here are a few possible options I thought of. Please debate, smack down, heckle, cajole, and add your own.

• Setup a wp-cron task that will periodically query AAD to ensure users are still valid. This would probably require the plugin to set a marker as to which accounts logged in via AAD initial. Should differentiate between pre-existing users and new users created via AAD. This also means that access to query for users from AAD needs to exist somehow.
• Add an option to block access to the password reset form. This could be easiest, however it prevents users from resetting their own password if AAD is not the only login method. Thus an option the site admin can set.
• Add an option to remove the login form entirely when using AAD. Again this method assumes AAD is the only login method. It also means if AAD settings went haywire the regular site admin would not be able to get into the site to fix it without editing code or the db to reenable the default login form.

Another plugin to look at that has attempted to implement similar scenarios is the WordPress.com SSO by Jetpack. For reference https://github.com/Automattic/jetpack/blob/master/modules/sso.php

[jtsternberg]

This also means that access to query for users from AAD needs to exist somehow.

With this commit, the aad-sso is saved to user-meta, in the _aad_sso_id key, so that can be the query hook.

[psignoret]

It's an interesting problem.

To do the first option proposed by @blobaugh, we would need to give the plugin application permissions to "Read directory data" (currently, we're only asking for delegated permissions, which require a signed-in user in addition to the application's secret key). We could then either do as proposed (wp-cron job), or simple check role membership on every sign-in (regardless of method). Honestly, I'm not a fan of application-only permissions, because the secret is already exposed to any admin anyway.

An alternative would be that if AAD groups -> WP roles is being enforced, and the user has signed in at least once via AAD, any password-based login should demote them to a subscriber. In fact, the more I think of it, the more I'm convinced that as long as AAD roles are set to be required, AAD sign-in should be enforced for this users as well.

So, here's my proposal:

• On log-in (regardless of method), check if current user was granted a role via AAD group membership. If they were, require they sign in with AAD.

It does introduce the risk of lock-out, but I think that can be addressed with a really good admin experience that prevents bad configurations.