I have a WebAPI that I have successfully secured with Azure AD. When I run it locally (through Visual Studio), trying to access the WebAPI end point via a browser gives me
Authorization has been denied for this request.
Which is what I would expect. Accessing the WebAPI through a client with ADAL library works as it should. A forms login screen pops up, and authenticates me and passes back a token, which I can then use in my WebAPI requests.
Something I wouldn't expect happens if I deploy the WebAPI to an IIS server, and have Windows Authentication enabled for the site. When I try to hit it the IIS WebAPI end point through a browser, I get a Windows Authentication prompt. If I successfully authenticate the Windows Authentication, the WebAPI serves the response.
I guess I would expect that the WebAPI would return the same "Authorization has been denied for this request". Windows Authentication shouldn't authenticate me to the WebAPI if I've configured the WebAPI to use Azure AD authentication.
My question is, is this expected behaviour, and if so, why?
I can see from one perspective that the WebAPI can accept authentication from any method that I've configured. But part of me thinks that since the Azure AD authentication is configured in the WebAPI application, and not IIS, it should take precedence.
Related
If I create an ASP.NET Core + Angular project and enable Windows Authentication (following these instructions link) and debug it using IIS Express, why does the Angular app load if I open the browser with a local user (runas /user:MY-PC\local-user Chrome.exe) which is not in AD? Shouldn't IIS Express ask me for credentials?
If I publish to Local IIS (with Windows Authentication enabled and Windows Hosting Bundle installed) using Web Deploy I get the same result, Angular app loads and Local IIS does not ask for credentials. I tried splitting the project with ASP.NET Core API + Angular, but I got the same result. I had to implement an endpoint with some logic to return 401 (not network user), 403 (network user but not in my AD Group) and a Guard in Angular to avoid loading the Component and 401 and 403 pages.
However, when I did publish to IIS on the server (manually, I created the website and copied the files, and installed Windows Hosting Bundle), I realized the behavior is different, the Angular app is not loaded and IIS always asks for credentials. If I put wrong credentials or click on Cancel, IIS shows 401. With the correct credentials I can access and browser will remember them, but if I close and open the browser again, I need to re-enter my credentials, which is a bit annoying.
IIS Express and Local IIS never ask me for credentials when I open a normal browser (using my AD account).
Why does 'IIS on the server' behave differently than 'Local IIS' and 'IIS Express'?
I've created an OpenID Connect identity provider using ASP.NET Core and IdentityServer4 and published it to Azure. I can authenticate with the provider using an MVC app that's hosted on my Azure VM, however, when I try to run the same app and access my provider from my local PC I run in to a 404 error. My provider website partially displays and looking at the traffic in MS Edge, my client app is successfully authorized via the authorize endpoint. CORS is also enabled for my client app with a record in ClientCorsOrigins. Looking for any ideas on how to get past the 404 and to the login screen for my identity provider.
Is your IdentityServer really available and reachable outside Azure?
I'm developing a blazor web application that will use windows authentication. The web application requires data from another web service. Basic authentication is required on the web service. The web application and web service are in the same domain using the same domain for authentication. Is there a way to take the windows auth credential that the web application will possess and convert it to the basic auth required by the web service?
I am aware that the windows auth credential does not contain the password and basic auth needs a password. I cannot change the authentication scheme of the web service. I cannot spin up a new instance of the web service with a different authentication mechanism. I can't use basic authentication for the web application. The web service requires that the web application connects with it using the logged in users credentials for logging purposes ie. can't just use a service account to connect to the web service. I am open to using a different authentication mechanism for the web application with comparable security to windows auth if it will work, SSO preferred.
I believe this is technically infeasible but would welcome any evidence to the contrary.
We have two webapi applications (core and support) configured on the same IIS web server running on our local domain. Our users authenticate on the core application using active directory and the core system returns a bearer token. This token is then used to authorize all API calls from our ReactJS client. In addition to the core application, we also have the support web application. Any calls to this system API end points also needs to be authorized.
Is it possible to use the same bearer token issued by the core application for the support application?
We have configured a separate webserver, database server and client to test the process. After building and deploying the two api web applications and the ReactJS client we are able to login via active directory, receive a bearer token and with this token authenticate on both the core and support platforms.
However, when we copy the same files and configurations to our clients server, we get a 401 authorization error on the support domain; the core domain works perfectly.
We have installed SSL certificates in both environments as well.
If we set the support application to Allow all Origins for CORS it works as there is no authorization. However, when we set the origins to the ReactJS and Core api projects we get the 401 error on the support domain.
We did not expect the token from the core application to authorize against the support application. However, this is working within our domain environment and we are not sure why. This has made it even more confusing as to why it does not work in the customers environment.
In case it helps anyone ... The reason this worked for us internally is because we had all web applications running within the same application pool. This meant they shared the same machine key and as such the bearer token from one would be authorized across all. As soon as we moved them into their own application pools we were able to replicate the same issue as the customer (ie. 401 authorization). The fix is to either have them in the same application pool or add the same machinekey to the applications web.config files.
HI all I am developing a web API that will be using identity impersonation (using always the same functional identity valid in my domain) to check the status of configuration files of some servers. To do that, I add this to my web.config file
I also set my IIS server to neglate anonymous authentication and accept windows authentication for web service. However when I try to access the status of the files from a browser I noticed that the API is still using NT AUTHORITY\NETWORK SERVICE as the user and, of course, the access to the remote files is denied. Does anyone have an idea of what am I missing?
Thanks
My fault, forgot to set the Authentication mode to Windows in web.config