@soumaz please can you debug and work out why this is. Unfortunately I do not have time to work the problem out at the moment.

@soumaz did you try setting the authPersistSingleRequest to True in your services windowsAuth settings?

Setting this flag to true specifies that authentication persists only for a single request on a connection. IIS resets the authentication at the end of each request, and forces reauthentication on the next request of the session.
The default value is false.

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/#configuration

So it all depends on how connections are being kept open or not between ocelot and the service ( didn't check). If they are kept open and you are on the defaults, then it makes sense that there is no reauth for the second user and setting authPersistSingleRequest would solve that.
Of course it would remove a perf optimization on the other hand.

I'm facing the same issue. I can confirm that it works with "authPersistSingleRequest=True"

I, I got the same issue and the "authPersistSingleRequest=True" also solved my problem

@soumaz, @mrauter, @Rick45

Can you please show how you have Ocelot configured to get NTLM working with anonymous gateway and windows auth protected services. I keep getting login prompts repeatedly and then a failure of not authenticated. Please show pertaining startup.cs and configuration file with AuthenticationOptions, httpHandlerOptions, etc.

Can't get Ocelot to work for us without this.

Good afternoon, I have 2 site in IIS. 1- ocelot api gateway. 2-i microservices.

When authorizing directly through site 2, I easily go to it and log in.

When using ocelot, the authorization window constantly creeps out and is not authorized.

the above tips did not help

Hello everybody,
we have also struggeled with getting Windows Authentication (Kerberos) working with Ocelot. At first we received 401 unauthorized constantly. In order to fix that we changed the implementation of the HttpClientBuilder class. After we added UseDefaultCredentials=true to the HttpClientHandler, we no longer received 401 unauthorized errors:

   private HttpClientHandler UseNonCookiesHandler(DownstreamContext context)
        {
            return new HttpClientHandler
            {
                AllowAutoRedirect = context.DownstreamReRoute.HttpHandlerOptions.AllowAutoRedirect,
                UseCookies = context.DownstreamReRoute.HttpHandlerOptions.UseCookieContainer,
                UseProxy = context.DownstreamReRoute.HttpHandlerOptions.UseProxy,
                MaxConnectionsPerServer = context.DownstreamReRoute.HttpHandlerOptions.MaxConnectionsPerServer,
                UseDefaultCredentials = true // this line make the difference
            };
        }

I guess setting UseDefaultCredentials=true is required to pass the kerberos tokens to the downstream service. It was also necessary to call ChallengeAsync to generate the WWW-authenticate header required for the Windows Authentication flow (see: #1144)

By the way setting authPersistSingleRequest alone, didn't solve my problem.

It would be great if Windows Authentication could be integrated into Ocelot, it's still used by a lot of people out there.

Thanks in advance.
Keep up the great work!

@ArminNaish Can you provide a basic working demo. I'm struggling to get ocelot working with windows authentication. I keep getting the windows signin prompt.

Hello @soumaz, I'm also having trouble with Windows Authentication. My setup is as following:

1. ASP.NET Core web app with Angular (SPA) and Ocelot gateway (v15.0.6.) running in IIS on server X
2. Katana self-hosted Web API running in a console app (.NET Framework 4.8) on server Y -> can't run in IIS because reasons...

When I hit one of the endpoints (/api/test or /api/hello) on the API itself from my workstation (so neither server X or server Y) with Postman setting Authentication to NTLM it all works fine (succesful requests, passes Authorize attribute, I see my Windows Identity name being returned). I have set up Fiddler as a reverse proxy on server Y which forwards requests to the Web API (project 2). I've done this so I can see all the requests coming in to the Web API.

When I try to hit the endpoints through the ocelot gateway however, I receive a status 400 response (no details), both in the Angular web app and when using Postman (see Fiddler screenshots below).

I've tried this both with Windows Authentication enabled in IIS on server X (following this recommendation on authPersistSingleRequest link ) and without, neither seems to work.

Any recommendations and help would be greatly appreciated!

This is the link to my repo. You would need to modify ocelot.test.json and \ClientApp\src\app\api-tester\api-tester.component.ts to set the correct gateway url

Project 1. is AngularWithOcelot
Project 2. is WindowsAuthenticationWithCorsHeadless

@ArminNaish commented on Mar 31, 2020

Hi @ArminNaish,

I'm wondering if this is truly the solution to the problem, in the light of this comment by Microsoft. Wouldn't that mean that credentials are set to the identity of the account under which Ocelot is running?

Regards, James

Hi,
I'am using ocelot (16.0.1) in a web api core (3.1) application (ApiGateway to manage web api core apps).
Using ocelot, I request services of a few web api core applications.
Every request is sent with Bearer Token to every app that works with a bearer token.
Therefore, I have one web api core app (say X) that is based windows authentication (and not like the others apps that work with bearer token).
So I would like to know if there is a way to catch the bearer token, in the apiGateway app, extract from it all the claims and use them to change the header authorization (from bearer... to NTLM...) and send the request to the app (X) ?
Thanks a lot in advance.
Aby

I created a PR for this: #1521

Did anyone actually manage to make this work?

@Sacrilege commented on Sep 23, 2021

Thank you for PR creation! Included in Dec'23 release.

@jpj90 commented on Oct 13, 2020

Indeed, James, we will ensure to double-check this during the testing phase of the feature delivery. We anticipate that the delivery may be complex, yet the issue has been given priority in the milestone. The upcoming release will follow the 23.3 Hotfixes.