I am using Microsoft.AspNetCore.Authentication.AzureAD.UI package.
And simple authentication in Startup.cs:
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
Everything works fine if I publish application to Azure Web App. But my application is inside Docker container and is located in AKS. External LoadBalancer working fine, but doesn't have SSL option. That's why I have tried to configure Front Door or Application Gateway. With no luck.
When I am using Gateway and setting reply URL to https://xxx.xxx.xxx.xxx/signin-oidc I am receiving
AADSTS50011: The reply url specified in the request does not match the
reply urls configured for the application
When to http://xxx.xxx.xxx.xxx/signin-oidc
AADSTS500117: The reply uri specified in the request isn't using a
secure scheme.
Similar story with Front Door and if to remove app.UseHsts() and app.UseHttpsRedirection()
Finally after all my troubles with Microsoft.AspNetCore.Authentication.AzureAD.UI + Kubernetes I have decided to use OpenID Connect
Related
As part of our Azure AD and HashiCorp Vault OIDC single sign-on implementation, I have registered an application in our corporate Azure AD and provided a couple of allowed redirect URIs in my Terraform configuration that are along the lines of the following:
allowed_redirect_uris="http://localhost:8250/oidc/callback"
allowed_redirect_uris="https://{hostname.domain}:8200/ui/vault/auth/oidc/oidc/callback"
The terraform configuration is provisioned via a GitLab CI/CD pipeline and manages to deploy successfully. However, when I then attempt to login into Vault via the UI (as shown below), I get a Microsoft Sign in error message pop-up which includes the following:
AADSTS50011: The redirect URI 'https://{hostname.domain}/ui/vault/auth/oidc/oidc/callback specified in the request does not match the redirect URIs configured for the application '{Azure Tenant Id}'. Make sure the redirect..............
Note: The URL displayed in the error message is somehow missing the port number 8200 which is definitely included in our Azure AD registered app redirect uri configuration.
I have even tried stripping out this same port number from my Terraform code and redeployed, all in an attempt to keep it consistent with the expected URI given in the error message. Yet still, this has failed to yield the desired result and I keep getting the same error.
Any idea what could be the issue?
Found one of the similar issue , please check if that could help .
According to discussion in similar github hashicorp vault issues
Vault’s OIDC provider should validate loopback IP redirect URIs
according to rfc8252 section-7.3 : The authorization server MUST
allow any port to be specified at the time of the request for loopback
IP redirect URIs, to accommodate clients that obtain an available
ephemeral port from the operating system at the time of the request.
This Feat/OIDC loopback redirect dynamic by paladin-devops hashicorp/vault · GitHub
discusses to add checks on OIDC provider to allow for redirect URI to have a dynamic port in the redirect URI if the loopback address is included in the OIDC client
References:
OIDC Provider Loopback Interface Redirection Issue- hashicorp vault (github)
hashicorp vault/OIDC loopback redirect dynamic by paladin-devops
GitHub
I have an application which I am trying to migrate to the App services. The authentication was windows auth before migration so I moved it to Azure SSO.
Background -
The application is registered within Azure to leverage single sign on
and we have a reply URL configured within the application and
redirect URI configured in Azure SSO for URL -
https://abc.customdomain.com
The app is hosted within App services and the Azure endpoint URL of
the app services is https://abc.azurewebsites.net
We have also setup a TXT record created within the custom Domain and
added this to App service to verify the ownership of the DNS.
The custom DNS https://abc.customdomain.com is configured and
pointing to the application gateway.
The application gateway is configured to point to the App service.
Issue
When I try testing the application the SSO works as expected but the moment it tries redirecting to the application after Sign on it breaks because of the incorrect redirect URL as the app services has the URL – https://abc.azurewebsites.net
After setting up a CNAME and pointing it to the App services the hosted site works, but we want to have the traffic flow from the Application gateway.
Sorry that my question might be repetitive but none of the solutions provided in other links have resolved my issue. Below is my situation
We have ASP.NET Core 3.1 Web application to which we are trying to use Azure AD so that users can login with our Enterprise Credentials. We started with ASP.CRORE MVC default template and enabled to Use Organization credentials and Authentication is working in our Local environment. We are now trying to deploy this app to other internal environments. So we have deployed this to two of our internal servers and configured IIS to refer this website with http IP's assigned. I was able to create Azure App registry for this application and was able to add the http IP's through Manifest, added the clientId to the appsettings.json file and the authentication is working if we refer the website using the http IP's. I have also tried by assigning https IP's assigned to the same websites and added them to Azure App Registry and again the authentication is still working if we refer the website with either of the 2 https IP's.
Now we have decided to create URL something like https://ourwebsitename.companyname.com which resolves to either of the http IP's using F5 Load balancer. I was able to add the URL to the azure app registry and using the same clientId in appsettings.json in the same way how the app is working with http or https IPs. But somehow when we refer the website URL
https://ourwebsitename.companyname.com we are getting the error as mentioned in the title of the question and I did observed after I hit the URL, its getting redirected as redirect_uri=httpXXXX instead of https which I thought may be the reason of the issue but unable to resolve. I have googled it and tried with various solutions but none resolved and so I am posing it again hoping for a luck if someone can provide me a solution.
Following are the links which appeared close to my situation but didn't work for me
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-5.0
https://github.com/AzureAD/microsoft-identity-web/issues/115
Thanks in advance.
I looked at the sample you provided, and it does not provide the redirect_ url key in appsettings.json. So, based on my experience, it should have a built-in redirect_ url. Otherwise, the aadsts50011 error will not be reported.
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
We have a React App which is hosted inside an ASP.NET Core site hosted on an IIS Server.
Originally we had the React App hosted on its own in IIS and protected by HTTP Basic Auth on our Staging server. This worked fine.
We then moved to hosting the React App inside the ASP.NET Core site. This has now caused problems with Basic Auth. If the user enters the site through just the domain they can authenticate with Basic Auth and everything works. However is the user refresh a page in their browser, the Basic Auth header is no longer sent and causes the server to challenge the user again for their username and password. For our testers this makes their lives very hard.
We have reproduced this in both Firefox and Chrome.
Using Fiddler we are able to request the pages/documents directly with the Basic Auth header, so we know that direct access is possible. We just don't understand why the browser is removing the header on a refresh.
IIS basic authentication is not cookie-based authentication. client just send user credential to client side with authorization header. It looks like the fresh page action will clean the cache or override that header. Please check this on other web browser like edge or IE.
I have a GAE app set up to use a custom domain, let's call it mycustomdomain. This naked domain is working fine over HTTP and HTTPS. I also have a service called api, it can be accessed successfully by going to http://api.mycustomdomain.com (custom domain convention).
However, I can't access the api service over HTTPS. I uploaded a SSL for mycustomdomain.com, but I got an error (site can't be reached) for trying to accessing the api service over HTTPS. My question is do I need to purchase the wildcard.mycustomdomain.com SSL in order to access the api service over HTTPS? I don't have much experience dealing with SSL certs and GAE custom domain, so any help would be greatly appreciated. Thank you!
Edit: updated information for GCP Console configurations.
My app setup in the Console contains the following:
Services: default, api
Custom domain setup: mycustomdomain.com
SSL uploaded: ultrahdlivewallpaper.com (NOT the wildcard version), api.ultrahdlivewallpaper.com (unable to be enabled for custom domain, none matching)
More detail: The problem is when I map both ultrahdlivewallpapers.com and api.ultrahdlivewallpapers.com, they are both mapped to the default service. I want api. to point to the API service. If I only map ultrahdlivewallpapers.com, that allows me to access api service at the api subdomain, but then the api SSL can't be applied to api. subdomain because it's not listed as a subdomain.
07/24/17 Update: I believe this is a limitation with the App Engine Settings after trying out several scenarios via GAE Console. We have a custom domain set up for ultrahdlivewallpapers.com and enabled the SSL cert for this domain. The domain is pointing to the default service. We have a second service set up called API. Google's routing rules for any service set up is via HTTP:// service-id.custom-domain, which in our case is api.ultrahdlivewallpapers.com. However, when I upload the SSL for the api subdomain, Console couldn't find matching domains because the api subdomain is not specified via the Console. Now if I set up api.ultrahdlivewallpapers.com as a custom domain, I'm able to enable the SSL for api subdomain. Problem then becomes api subdomain is now pointing to the default service instead of the api service. If I remove the api mapping, I'm able to browse to the api service again, but no HTTPS! I don't believe there is a way to get this set up correctly without a wildcard SSL enabled for all subdomains. Please let me know if I'm missing anything. I have tried everything I can think of via the Console. Thanks.
You don't necessarily need a "wildcard" cert, per se. But, you do need to get a cert that covers all the subdomains. For example:
mycustomdomain.com
www.mycustomdomain.com
api.mycustomdomain.com
It's a standard solution, and not difficult to do. Certbot (Let's Encrypt) makes it easy.
If you choose to get a wildcard certificate installation is pretty straight forward:
You upload the certificate in the developer console (in App Engine -> Settings -> SSL Certificates -> Upload a new certificate). May require a bit of effort, see also Google App Engine SSL with Let's Encrypt "could not be inserted".
Once it's visible in the certificate table you can click on its name and you'll end up in the certificate edit screen where you can select which custom (sub)domains it applies to (from the list of all custom domains mapped in the app), looks like this:
Note: these are the corresponding custom domain mappings:
If you have another app (under the same admin account) which is also mapped to subdomains of the same domain you can activate the certificate on it as well in a similar manner (the console automatically shows the certificate in the list when you switch apps, no need to upload it again).