Marco

Hello,

I refactored the whole file to remove some return values that would cause the template handler to continue to the default template, thus ensuring it never does (when handling an sso_for_azure_ad URL) and always returns appropriate errors instead.

Hello,

I can confirm excluding the only URLs that need to be accessible without logging in are the start and callback URLs.

However, the exact values that need to be excluded may vary depending on whether the “Use rewrites” option is enabled.

The exact URLs for a particular site are displayed in the plugin’s options page.

• This reply was modified 10 months, 1 week ago by Marco.

Hello,
the only URLs to unblock for this plugin to work should be those shown in the options page, although they should be allowed to contain additional query parameters.

Simply unblocking all URLs containing “sso_for_azure_ad” may cause unintentional side effects allowing access to other pages.

Hello, I was planning on testing the Force Login plugin before replying, but if it allows for exceptions to be created, then adding exceptions for both the Start and Callback URLs may make login work.

Hello,

this plugin adds the ability to sign in to WordPress with an Azure AD login. Adding functionality to lock the entire website behind the AAD login is out of scope for this plugin.

After a search I was able to find some plugins that require the user to log in before being able to access the site (I won’t name any here because I haven’t tried them and therefore cannot vouch for them).

If the plugin redirects the user to the regular wp-login.php page the “Login with Azure AD” button will appear, allowing login with AAD. This plugin matches AAD users to WordPress users and logs them in with the latter, therefore any plugin that expects a visitor to be signed into WordPress will see the user as “signed in” if they have logged in with AAD through this plugin.

I was referring to the regular WordPress login cookies.

This plugin does not use cookies itself, instead it uses WordPress’ nonce feature, which relies on an IP address for logged out users and a login cookie for logged in users.

If a user is already logged in when they start the SSO process (i.e. visiting the /sso_for_azure_ad/start/ or ?sso_for_azure_ad=start URLs shown in the plugin settings) then there may be issues if WordPress cookeis are set to SameSite=Strict, since the user would be issued a nonce tied to their login cookie, but their browser would not present that cookie to WordPress when getting redirected from the Microsoft login page back to the plugin callback page, which would then cause nonce validation to fail.

The state parameter looks correct, however I am having trouble reproducing the issue.

The login process relies on WordPress nonces, which get invalidated after logging in or when changing IP address.
Therefore, I see three possible ways to cause this issue:

• The user’s IP address changes between when the plugin redirects them to Microsoft for login and when they return; or
• The user is already logged in and uses the “Homepage / Login URL” in the plugin settings to access the site (for example, form the Office.com homepage) and login cookies are set to SameSite=Strict, which means they won’t be presented by the browser to the website when returning from Microsoft.
• The user logs in in another tab or window during the portion of the login process that takes place on Microsoft’s website.

I realize these scenarios are very unlikely. I was unable to come up with other options to trigger this error.

A list of other plugins in use may be helpful to attempt to replicate the error.

If the URLs I previously mentioned are correctly being rewritten to be handled by WordPress I honestly do not have any ideas on why it does not work.

I might test my plugin again in the next few days on the latest WordPress to ensure that it did not break in a way that I missed.