Please provide your approval to set the license on this project to an MIT license.

@blobaugh
@ntonyho
@jtsternberg

Fatal error: Cannot redeclare class JWT in /wp-content/plugins/aad-sso-wordpress/lib/php-jwt/Authentication/JWT.php on line 17

Upon activating the plugin, this error comes up.

Using WordPress 4.2.2

Also using Zendesk with SSO activated: https://wordpress.org/plugins/zendesk/

Thank you for a wonderful plugin that has so far worked well for authenticating users without groups. We are trying to connect users to groups but cannot find the Azure Group Object ID for the groups we want to map into WordPress.

Can you direct me as to where I can find these IDs?

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

Hello,

I did everything and now when i am at the /wp-admin i try and log in with my active directory login and then it just gives the normal wordpress failed password.

Right now mapping the authenticating user's AD group to a WP role is enabled by default and can only be changed by altering the plugin at runtime. We should add in a checkbox to the settings page in wp-admin to dis/enable mapping easily by the site admin.

Rather than displaying tame/helpful errors, this plugin will emit errors upon activation if allow_url_fopen is false.

(pull request coming)

Unit tests should exist to the fullest extent possible.

Resource: https://pippinsplugins.com/unit-tests-wordpress-plugins-introduction/

Lets add a filter that allows developers to add addition custom user roles via a filter.

I have setup latest stable wordpress on blank cPanel server and created Azure AD as your instructions.
I have setup successfully about 7 sites, but two of them are not working.
I have tried replacing your wp-plugin, and recreating in Azure AD side, however no success.

The error after login is on wp-login.php form showing error: ANTIFORGERY_ID mismatch. Expecting
without any ID.

What can be the issue ? how can I clean and place again your plugin without any cache, cookies or smth, please give me more to troubleshoot, otherwise its a bug error.

my Settings.json same for all sites (different url and IDs of course):

  {
    "org_display_name": "My company site",

    "client_id":        "66cec22g-ac19-4201-acbd-73e4477f8bc8",
    "client_secret":    "D8Nk3tTiU2cMfiNHh4VwPJ7jfQ49BsCBDc05xaUZ4QM=",

    "field_to_match_to_upn": "email",
    "enable_auto_provisioning": true,

    "enable_aad_group_to_wp_role": true,
    "default_wp_role": null,
    "aad_group_to_wp_role_map": {
            "21e0165b-085e-4z4b-a965-e7bfed9deef0": "administrator"
    }
 }

Resource: https://help.github.com/articles/setting-guidelines-for-repository-contributors/

When deploying a blog behind load balancers (e.g. Azure Web Sites), session affinity is required. Otherwise, the redirect back after sign in won't necessarily get the same instance of the site, and won't find the session. The ANTIFORGERY ID will not match and sign in will fail.

This should be documented, as its really hard to debug. :)

For IIS: http://azure.microsoft.com/blog/2013/11/18/disabling-arrs-instance-affinity-in-windows-azure-web-sites/

It is possible to load and view the Settings.json file by navigating to it with an HTTP request. For the most part, these credentials SHOULD BE read-only, but there is a possibility that these credentials would include the ability to write to AD.

This could be expose a serious attack vector for users that haven't properly configured their Azure AD tokens.

1. Saving these credentials to a PHP constant in wp-config.php.
2. Saving these credentials to a PHP environment variable $_ENV['ad_client_token']
3. Mimic WordPress' behavior where these settings files can be placed one directory above the public html directory
4. Save these credentials to WordPress DB and allow configuration via WordPress administration.

processToken() sets a few SESSION variables used by GraphHelper, so need to add it back in (and actually call it after getting a token).

In reality, GraphHelper should not rely on obscure SESSION variables...

Rather than using the object IDs, if the current user is signed in via AAD, the groups field should allow for searching.

Hi,

when testing this out, we discovered that some users with existing accounts in WP had lowercase email addresses, but the email address stored in Azure AD was Proper case... and this failed to log users in.

Other than that - awesome plugin - great work!

When matching AAD's UPN to WordPress' email, a users can easily lock themselves out by updating their profile to change their email. Since an average AAD user can't change their own UPN, this would be a bad thing.

(On the next login, the user would not be matched via email, but might not be auto-provisioned because of a conflict with login field (see issue #13)).

Hi Philippe,

Great plugin, thank you for your efforts.

I ran in to an issue when configuring it on our site, as we have enhanced security using iThemes Security Pro plugin which allows you to hide the typical wordpress login urls /wp-admin/, /wp-login.php, etc and replace them with a custom one such as /secretloginpage/. This means I have to set the reply url in my azure ad application to /secretloginpage/ instead of /wp-login.php. However this creates an issue because the redirect_uri parameter in the login link query string is harded coded on line 49 of aad-sso-wordpress.php to wp_login_url() which produces a url ending in /wp-config.php. This causes an error in Azure AD - Error: AADSTS50011: The reply address ‘https://someurlhere’ does not match the reply addresses configured for the application: xxxxxxxx.

It would be very handy if redirect_uri variable could be overridden on the settings page instead of resorting to modifying the plugin code which I've done as a temporary work around.

Many thanks

I created a WP website
Added "restricted site access" plug-in
Added "aad sso wordpress" login

I can successfully log in now with AAD credentials; however, every time I log in, I get redirected to the profile page. This is not the case when I log in with WP credentials - I get directed to the home page.

For WordPress plugin directory

All the settings that take a default setting should be shown in the UI, probably hidden by default.

request to AADSSO_GraphHelper::userCheckMemberGroups() returns this error:

stdClass Object
    (
        [odata.error] => stdClass Object
            (
                [code] => Authorization_RequestDenied
                [message] => stdClass Object
                    (
                        [lang] => en
                        [value] => Insufficient privileges to complete the operation.
                    )

            )

    )

Which means there's no way to properly map a user. Do you know the reason for this?

We might want to consider using OpenID Connect.

(There are some arguments not to do so, but creating this as a tracking item just in case.)

Any thoughts on support for Azure AD B2C Directory?

Make sure all strings are localized properly.

When every user first logs into the Wordpress site via SSO, Azure requests permissions for the app:
"[App Name] needs permission to:
Sign you in and read your profile
You're signed in as: [User Name]"
It's not clear how to grant permission on behalf of our organization's users. If you have worked through this already, it would be an excellent addition to your setup instructions. After granting permission individually, SSO works great!

Curious if there is any reason you prefer this to not be the case.

https://developer.wordpress.org/plugins/the-basics/activation-deactivation-hooks/

We can't create a user in WordPress if the email address is taken. If we are matching by email (field_to_match_to_upn = 'email'), then the auto-provisioning code is never invoked. However, if we are matching by login (field_to_match_to_upn = 'login'), then it is possible that there exists a user with the same email, but with a different login.

E.g.
field_to_match_to_upn: login
User in WP: (login: admin, email: [email protected])
User signing in: (UPN: [email protected])
Will attempt to auto-provision because no users were found where login == '[email protected]', but auto-provision will fail because there already exists a user where email == '[email protected]'.

Proposal: Better error message, and (optionally) fall back to alternate matching method if preferred one fails.

I feel like I have all the settings set properly. Two nearly identical instances: one works fine, the other is having issues. The two Azure applications are set-up identically. I am very open to ideas and suggestions.

Consistently getting:
ANTIFORGERY_ID mismatch. Expecting {5001CD3E-DD9E-7999-EECA-14B6A9F6606D}

The entire process for setting up the plugin has changed and the readme file should be updated to reflect these changes

We need to ensure the proper login hooks for WordPress are being called. This is so security and logging plugins continue to work as expected.

I have the plugin installed on my site for more than 6 months, this week we started to receive the following error when trying to login
ERROR: Invalid id_token. Cannot handle token prior to 2015-12-01T10:39:32+0000
(the time stamp is when you tried to login)

I haven't made any changes to the server or the application in Azure.

Why is this happening but more important how do i fix this ???

Thanks
Josef

Hour-long expiration should be safe?

Should validate the access to token (otherwise, open to MITM).

I have found the following helpful resources for prepping a plugin for the plugin directory

• http://jeremypry.com/wordpress-plugin-development-with-github/
• https://wordpress.org/plugins/about/
• https://wordpress.org/plugins/about/guidelines/

Todo...

• Create README.txt
• Logo?
• GitHub <-> WordPress SVN sync mechanism

The current version of the plugin in the WP plugin directory is from a Subversion repository (assigned by wordpress.org), so an automated way to push commits from GitHub to Subversion would be nice. This service seems to handle the process nicely: http://ship.getherbert.com/ If we don't want a third party service, building our own Git<->SVN plugin sync shouldn't be too hard. GitHub Webhooks would make this totally automatic.

logging out successfully changes the role of the given user in WP to "none"

Some installs don't like file_get_contents.

Current implementation has the group ObjectId as key, and WP role as value. WP roles are the ones that are unique, and thus should be the keys. This would avoid awkward flipping and non-deterministic behavior.

When a new user authenticates via SSO (office 365) the plugin creates the users account in wordpress and authenticates them for access. If the user logs out of office 365 and attempts to login, this time using the wordpress login form and enters their office 365 email/password they are not authenticated to the wordpress site.

This came about when trying to setup a blogging software (MS Word and LIve Writer) to authenticate to the blog.

Need to explore a mechanism to generate state values only when generating the sign-in link, not necessarily on every request to wp-login.php.

As a case study: The MAYO - Login Screen plugin allows the user to set a background image for the login page. In doing so, it adds this style:

.login { /* ... */ background-image: url('http://url/to/background/image.png'); /* ... */ }

However, if the user does not set a background image, this will result in the following CSS:

.login { /* ... */ background-image: url(''); /* ... */ }

The issue is introduced by url(''). When the browser tries to load the image at '', it makes a request to the current page (typically .../wp-login.php). This loads and invokes all plugins (including the AADSSO plugin) a second time, which will re-generate the ANTIFORGERY_ID value in the session.

But since the value in the sign-in link was generated before all this happened, the Authorization Request goes ahead using the original value of the ANTIFORGERY_ID, which results in the mismatch and error message: "ANTIFORGERY_ID mismatch".

Probably useful to include instructions using Office 365 portal, Azure portal, and AAD PowerShell.

Instead of UPN

Needs more investigation, but basically, often error messages are not displaying in the login form (e.g. when not a member of the groups).

I've setup the latest version but not sure how to enter multiple groups. How or can the plugin setup accommodate multiple groups for the same role (eg. 2 groups both have administrator access).

If the plugin notices the settings JSON path is set, offer to import those settings into the database.