We were able to test by setting up an app registration using a personal Microsoft ID. Instead of creating a certificate we just used a “client secret” (application password):
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret
What step are you getting hung up on, and do you have any server logs about the errors?
One thing to check is that you’re using the correct client id and secret values, they are poorly labeled in the Azure portal:
https://github.com/MicrosoftDocs/azure-docs/issues/37847#issuecomment-760544779
I had the wrong Secret value. Had used the ID. Created a new one and added the value successfully.
I now get an error saying the “Sorry, that email address is already used!” All our usernames we added using CAS and is just username, not [email protected]. But each user account has email. For example, my account has username = nielsen and email = [email protected]. I’m guessing the Azure AD connection is trying to create a new username called [email protected]. I can try adding a new API permission and see if it can grab username. I am more familiar with creating connections via the Enterprise Application feature vs App registrations 🙂
I tried first creating an enterprise app entry so that I could transform username to just use the email prefix. Then took that app to create a new app registration entry in order to create a client secret. Was able to make a connection, but keep getting an error message that permissions need to be approved by admin. We’ve tried removing any api permission as well as adding in app registration graph entries for email, openid, profile, and User.Read in an effort to cover our bases (and had Grant admin consent applied throughout) with no luck. I believe there is some conflict in the method I am using by combining enterprise application with app registration, but haven’t been able to figure it out (if it is even possible).
Just using app registration, I don’t believe there is an equivalent to grab username and remove the prefix like in the SAML claim options for enterprise applications.
Also, I ran into a side issue since we are running multisite. I could be wrong, but it seems to only work if I add a Reply URI for each sub-site. I cannot add the main network URL.
For Azure, Authorizer will fetch the resource owner and check for email and preferred_username attributes:
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L460-L465
If no username is found, it will use the email (with the @domain portion stripped out):
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L486-L493
I’m not sure how you’re ending up with the “Sorry, that email address is already used” error; WordPress will do that lookup on the account email, not the username. Maybe something with the multisite environment? Have you confirmed that there actually isn’t another account with that email? WordPress multisite only has one wp_users table for the entire network, and then just flags which subsites individual users have access to.
Regarding multisite redirect URIs, I think you can use wildcards in Azure redirect URIs but only for school/work accounts. So something like https://example.edu/*/wp-login.php
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url#restrictions-on-wildcards-in-redirect-uris
I think there are some possible CORS conflicts. Have tried using various combinations of Web versus Single-page application set up for the URIs with no luck. I can get direct matching with full URLs, but not using wildcards. I did have to add the wildward via the Manifest as it blocked me from adding via the interface. All our test instances have very different URLs that our main prod due to the way our hosting partner manages those.
Regarding the email already used error, it is for my account and I only have one with my email. It’s set to prevent duplicates as is. I wonder if the way I have it configured in the app registration isn’t passing the email correctly so then the Authorizor code can’t correctly perform the explode function and correctly create the username variable? I’ve tried adding different option tokens to see if that would help with no luck. I also tried adding more API permissions with no effect as of yet.
Wildcard re-directs appear to only work at the start or end of the URL string, but not in the middle.
So this worked:
{
"url": "https://*.myschool.edu/*",
"type": "Web"
}
But this did not:
{
"url": "https://www.myschool.edu/*/wp-login.php",
"type": "Web"
}
For the email issue, I was able to replace username with emails via the database (xxx_users table) and update superadmins (xxx_sitemeta table, searching for meta_key=site_admins).
Doing the above got me 90% the way to replacing using CAS. I noticed that there is no option to allow automatic login like you can with CAS. Usually not a big deal, but we have a few sites where links re-direct folks to the front end. But by using Azure AD approach, it always takes the user to the back end and prompts for login even if they are logged in already via another application (so not real SSO 100%). For example, we have an emergency alert system that uses WordPress posts to share full event descriptions. All these posts require login. Usually we link students, faculty, and staff to these posts. In testing this with the Azure AD option, after logging in, it re-directs folks to the backend instead of the post. CAS takes you to the front end post. For example, if the password reuired post was https://www.myschool.edu/alerts/2022/12/24/snow-day/ Azure AD authentication takes you to the admin dashboard. CAS re-directs to the post after authentication. I supposes this is a separate issue, but could the Azure AD oauth option allow for the same re-direct and SSO akin to CAS?
-
This reply was modified 3 years, 7 months ago by
manakuke.
We’ll look at those login redirects on Azure, thanks!
We have a fix for this that will be included in the next release:
https://github.com/uhm-coe/authorizer/commit/a3d28a91c4ef6bdb32a567f4e5073ed250577ee3
(You can test it now if you clone the plugin from github.)
Thank you for your on-going support for this plugin.
Aloha version 3.6.0 has been released with this fix, let us know if you run into any issues or have more feedback!
The process of integrating Azure Active Directory (Azure AD) with an application can be complex and may require several steps, including creating an app registration in the Azure portal, configuring the application with the appropriate permissions and certificates, and ensuring that the application is properly configured to communicate with Azure AD.
To get Azure AD to play nicely with your application, it is important to first review the documentation and tutorials provided by Microsoft to understand the steps required for integration. It is also helpful to review the Azure AD troubleshooting guide in case you encounter any issues.
If you are still having trouble with the app registration process, it may be helpful to reach out to Microsoft support or to consult with an experienced developer who has experience working with Azure AD.
Please note that if you are using a plugin, it may have additional requirements or dependencies that you need to be aware of, and the plugin’s documentation should be consulted for more information.
AutinJoy
microsoft azure expert msp
