I am hosting Sonarqube on windows VM with IIS and reverse proxy configured to support SSL certificate.
All works for basic (user/password) authentication but I got problem making Azure AD authentication work
I followed instructions to setup Azure AD integration. I have configured Azure AD integration, provided correct Client ID, new Secret, correct tenant ID, Base server url is correct no ending "/".
Despite all steps executed properly Azure AD authentication doesn't work: when I click on button to logon using Microsoft login page sends requests and I am redirected back to logon page
I use Sonarqube 8.0.0.29455 with plugin Azure AD Authentication version 1.2.0
Please check with below points:
The redirect URL should be configured with a correct URL,
e.g. https:// sonarqube.example.com/oauth2/callback/aad. Here /oauth2/callback/aad is a must in addition to the application URL. The redirect URL must have a https or loopback address, else the Azure AD login will not work.
For example, if your main URL is "https://sonarqube.example.com", you would enter "https://sonarqube.example.com/oauth2/callback/aad"
Set the required permissions in portal and grant consent if required
i) Sign in and read user profile
ii) Read all users’ basic profiles
Check the rewrite rule when Running SonarQube behind an IIS Reversed Proxy | Microsoft Docs
Make sure you aren’t behind a firewall .
Try upgrading sonarqube
Restart everything after any changes made.
References:
Setup · hkamel/sonar-auth-aad Wiki (github.com)
Azure AD integration with sonarqube - Stack Overflow
Related
We were trying to enable AppGateway on one of our WebApplication hosted on AppService which use OpenIDConnect to Auth the request against Azure AD using Code with PKCE flow.
Since our *.azurewebsite.net url is going to be private, we had to update the "Redirect URI" in AAD and in the Web.config to rout the request back to AppGateway after Authentication and then with the Authenticated Payload the request should hit the Backend Pool which has the AppService.
But, every time we try this configuration we ended up being in an Endless Loop between
AppGateway --> AppService(BackendPool) --> Authentication page --> AppGateWay -->...
• You are encountering the endless loop when setting up the application gateway in front of your app service because the reply URLs set for the app service on the application gateway may not be correctly configured due to which even after redirecting to the configured reply URLs, you are not able to go to the set app service page after authentication. For this purpose, kindly go to the ‘Authentication/Authorization’ blade on your app service, click on the “Azure Active Directory” option. In there, click on “Manage Application”. This will take you to the Azure Active Directory configuration. In that, select the ‘Express’ mode, and select the option for ‘Manage Application’, and in that select “Reply URLs” in the “Settings” blade. This will open the various reply URLs that the application is able to use to send an authenticated user back to your application.
• If you configured your custom domain before setting up Azure Active Directory authentication, both your ‘*.azurewebsites.net’ and custom domain URLs should be configured for the reply URLs. If your custom domain is not there, be sure to set up the reply URL as ‘https:///.auth/login/aad/callback’. Once the said has been set up correctly as specified, you should be able to authenticate using either the custom domain or the *.azurewebsites.net hostname to ensure you can sign in.
• Ensure that you change your custom domain from pointing to the App Service to pointing to the Application Gateway's public IP or DNS name. This change is made in your DNS registrar.
Finally, I would suggest you to please refer and go through these below documentation links for more details on configuring the app service for custom DNS/default domain and AAD authentication: -
https://learn.microsoft.com/en-us/azure/application-gateway/configure-web-app?tabs=customdomain%2Cazure-portal#configure-a-web-app-behind-an-existing-application-gateway
https://learn.microsoft.com/en-us/archive/blogs/waws/setting-up-application-gateway-with-an-app-service-that-uses-azure-active-directory-authentication#setting-up-the-application-gateway
I created a blazor server app like this:
That works fine on my local machine. However, when deploying the website to azure I get the following error message: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application
In the azure portal I navigated to the enterprise application that was automatically created during the project creation in visual studio. However, the "Homepage URL" is readonly.
How can I make this work?
Method 1:
Instead of Enterprise application go to App registration click on Authentication under Manage group, in Authentication Menu you can specify redirect URL.
Method 2:
You can modify application manifest for redirect URL and save it after modification.
Considering AAD application is created using your own account you should be owner of this application and can be able to modify it.
Let me know for any question, happy to help!
I have a NodeJS Application utilizing OAuth2. I do not have SSL. I am trying to authenticate using Single Sign-on with Microsoft. While it works on localhost, it doesn't work with network's IP. Any idea?
On MS Website it says I should be able to:
The Azure AD application model today supports both HTTP and HTTPS
schemes for apps that sign in Microsoft work or school accounts in any
organization's Azure Active Directory (Azure AD) tenant. That is
signInAudience field in the application manifest is set to either
AzureADMyOrg or AzureADMultipleOrgs. For the apps that sign in
Personal Microsoft accounts and work and school accounts (that is
signInAudience set to AzureADandPersonalMicrosoftAccount) only HTTPS
scheme is allowed.
I have the Manifest set to AzureADMultipleOrgs
The redirect URL should still be using HTTPS,
In general, they do not support transmitting tokens over unsecured channels. Currently, apps that are registered in the Application Registration Portal are restricted to a limited set of redirect URI values. The redirect URI for web apps and services must begin with the scheme https.
I've registered an app in Azure AD and can successfully authenticate users against it while running on localhost.
The Azure AD app's Redirect URI is set to https://localhost:44352/sigin-oidc and the Logout URI is https://localhost:44352/signout-oidc
If I deploy my MVC app to Azure the host name will be different from "localhost". Do I have to register another app for deployment or just add a second redirect URI? But what about the logout URL then - only one can be configured there?
Second redirect URI. Here are some pointer on restrictions on redirect URIs.
Logout URI is only relevant to your application. Not the application registration.
If you are referring to the post_logout_redirect_uri, as described here - it must registered in the redirect_uris as well:
Or if you consider the logoutUrl as described in the Manifest - that is only used when you perform a Single-sign-out of all web apps, as described here. Frankly, there are very few reasons to use the single sign out capability of Azure AD. And, it requires of course that all apps are configured for single sign out.
I have an Azure AD (with AD connect syncing it to local AD). I added a new On premise mobile management application through AAD-> Mobility(MDM and MAM)-> Add application ->On-premise MDM.
I have configured the terms of url and discovery url to my MDM server and checked that link is reachable and working.
I have assigned Enterprise mobility license to the user.
When I try to join an existing windows 10 device to AAD the terms of use url is not rendered, instead it throws below error.
If I remove the MDM application the AAD join is successful.
I have checked license and URL access what am I doing wrong?
After a lot of debugging we figured the issue was due to app-id uri not being set in the app.
You can set the app-id uri using following
Navigate to app configuration->Expose an API
The option to set the app-id uri is on top,you can set it as your on-prem application uri.
The msdn documentation is here.