Why does 'IIS on the server' behave differently than 'Local IIS' and 'IIS Express'? (ASP.NET Core + Angular + Windows Authentication) - api

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'?

Related

.aspnetcore.identity.Application cookie not set in the production environment

I have created a abp.io version 7.0-rc2 solution using the starter template.
I have chosen a tiered solution with separate authserver project(OpenIdDict) and Blazor-server as UI project. The solution works fine when I launch the AuthServer, HttpApi.Host and Blazor server UI client on localhost using development environment.
But this doesn't work in the production environment with nginx reverse proxy and using kestrel to serve the application.(The Https configuration has been done.)
The issue is, that the admin does not have some permissions after login, although I have checked with the database, all the permissions have been granted to admin.
I have checked the cookies of the blazor project domain in my browser, the .aspnetcore.identity.application cookie is not set. Of course the permission check will not pass without cookie.
The cookie has been returned from the authserver while logging in. The set-cookie does exist in the response header from authserver login form submission, as I checked using browser developer tool, but not set finally to the browser after the login process.
Then I made an experiment. I made changes to my appsettings.development.json in my blazor server UI project to let the AuthServer and HttpApi.Host running in the Production environment, and run the Blazor server on my development pc(localhost), let the blazor server using the production authserver and call the production API server too. Only the blazor server ui itself is running locally. It works then fine. The aspnetcore.identity.application cookie(localhost domain) is then successfully set to the browser.And the permissions are also successfully authorized.
I am not quite familiar with how the cookies are set in asp.net or Abp.Could somebody give me a hint, what could be the problem in the production environment? Or what should I check to find the problems out?
Thank you very much.

ASP.NET Core Windows Authentication pass through from UI website to API

IIS on Windows Server 2012 setup with 2 projects:
example.com: ASP.NET Core MVC project with VueJS as javascript framework.
api.example.com: ASP.NET Core Web API project whichs feeds the UI project.
The example.com is setup using Windows Authentication, the api.example.com is setup with both Anonymous and Windows Authentication.
Both projects have a seperated Application Pool.
Everything is working fine except when I go to the example.com website, I get a prompt to input my AD credentials for example.com, after that I get another one for api.example.com.
So the user needs to enter his credentials twice. Is there a way to reduce this to one and send the credentials to both websites?
I am using Google Chrome as browser to use the website.
Ok reduced the login to zero. Disabled the Windows authentication on the example.com because all authentication is done on the API project so no need to apply it here. Then added the api.example.com under Internet Explorer > Settings > Security > Intranet sites and kow the client can work directly without applying credentials when working inside the domain.

Deploy Azure AD WebAPI to IIS, with Windows Authentication enabled, skips Azure AD Authentication

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.

MVC web API identity impersonation

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

ADFS claims based SharePoint 2010 and embedded IFrame ASP.NET claims aware application single sign on

I have a SharePoint 2010 web site configured for Claims only as the Replying Party to ADFS. I also have an ASP.NET application configured for Claims using WIF + Extension for SAML 2.0 CTP as the Replying Party to the same ADFS server.
If I navigate to SharePoint, I get redirected to the ADFS server (https://.../adfs/ls?...) and presented with a Windows Login prompt. If I then navigate in the same browser instance to my ASP.NET application, the redirect occurs quickly to the same ADFS server, automatically authenticates, and redirects back to the ASP.NET application without a security prompt. As in How to share authentication context between a SharePoint 2010 Site and ASP.NET applications.
The issue occurs when I embed the ASP.NET application within an IFrame in a SharePoint web part. When starting a new browser instance and navigating to SharePoint, I get prompted the windows login prompt. As the page loads up to the IFrame I then get a second Windows Prompt for the same server for the embed ASP.NET application. If I cancel the prompt I get a 401 Unauthorized in the IFrame. If I navigate to the ASP.NET application, I am not prompted and it logs in automatically. Navigating back to the SharePoint application, the page will load including the IFrame content without prompts.
The SharePoint Endpoint is using the WS-Federation Passive Endpoint to https://sharepoint:port/_trust/ with binding POST.
The ASP.NET application Endpoint is using SAML Assertion Consumer Endpoints https://aspnetapp/ with binding POST and Artifact.
The Claims passed from both contain all required for each application.
Does anyone know how to prevent the second login prompt when using an IFrame in SharePoint?
It now works as expected with single sign-on after updating to System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0 from the now built in WIF classes. I'm assuming there was a compatibility issue with the Microsoft.IdentityModel.Web.Saml2AuthenticationModule SAML 2.0 CTP extension that was never finished.
Just a shot in the dark but assuming the custom ASP .NET application and SharePoint are on two separate machines, then there may be some subtleties regarding kerberos given that the ASP .NET page is in an IFRAME - it could be that a kerberos ticket needs to be passed between SharePoint to ASP .NET.
HTH.
This is only a guess but I believe that this is because both sites, the Sharepoint site and the embedded asp.net site from the iframe, start to load in the same time.
As both are not authenticated, they both go to the Adfs. But because you are not authenticated, the Adfs starts the 401 challenge, asking for the authentication. However your web browser does not present both login prompts in the same time. Rather, you get the first login prompt and when you sucesfully login, from the very moment the Adfs will retain the authentication so that any other site coming for claims will get them for free. But the inner site, the asp.net one, has already started the login process! Your browser does not know this and forces you to continue login.
As a conclusion, my idea would be to have a sharepoint page which requires authentication and which then redirects to ANOTHER page which has the asp.net site in an iframe so that your browser will not try to start the login sequence for both sites at the same time.