Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ocelot not working with a Windows Authentication #657

Open
soumaz opened this issue Oct 11, 2018 · 17 comments · May be fixed by #1521
Open

Ocelot not working with a Windows Authentication #657

soumaz opened this issue Oct 11, 2018 · 17 comments · May be fixed by #1521
Assignees
Labels
accepted Bug or feature would be accepted as a PR or is being worked on Dec'24 December 2024 release feature A new feature high High priority
Milestone

Comments

@soumaz
Copy link

soumaz commented Oct 11, 2018

Expected Behavior / New Feature

Ocelot should be working with Windows Authentication

Actual Behavior / Motivation for New Feature

Ocelot should be working with Windows Authentication

Steps to Reproduce the Problem

My gateway is a virtual directory hosted under default site with anonymous access.
And my services are hosted under another virtual directory with windows authentication enabled.

Note: - in IE options settings for "Enable Integrated windows authentication is enabled" from user machine. This is required otherwise the domain.com will not carry the identity.

Default website
----> Gateway = anonymous
-----> services = windows authentication.

With this from user machine when we call with servername.domain.com/gateway/ to get the user name from services, we get the user name for first user.

When the same url is hit by another user he gets the username of the first user, whereas the should have got is his own user name.

what we see is that persist-auth in headers is set to true for communication between gateway and services.

If we enable
----> Gateway = windows authentication
-----> services = windows authentication/anonymous

Authentication does not seem to work even if we add/remove testkey= "Windows".

Please assist on the same.

Specifications

  • Version:
  • Platform:
  • Subsystem:
@TomPallister TomPallister added the question Initially seen a question could become a new feature or bug or closed ;) label Oct 13, 2018
@TomPallister
Copy link
Member

@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.

@CJHarmath
Copy link

@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.

@philproctor philproctor added the needs validation Issue has not been replicated or verified yet label Jan 9, 2019
@mrauter
Copy link

mrauter commented Jan 13, 2019

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

@Rick45
Copy link

Rick45 commented Mar 22, 2019

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

@cjsmith26
Copy link

cjsmith26 commented Sep 20, 2019

@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.

@bodagovalex
Copy link

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

@soumaz
Copy link
Author

soumaz commented Oct 29, 2019 via email

@ArminNaish
Copy link

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!

@daudihusbands
Copy link

@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.

@soumaz
Copy link
Author

soumaz commented Aug 18, 2020 via email

@jpj90
Copy link

jpj90 commented Oct 8, 2020

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).

ocelot_fiddler_400
ocelot_fiddler_401

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

@jpj90
Copy link

jpj90 commented Oct 13, 2020

@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

@eventaka
Copy link

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

@Sacrilege
Copy link

I created a PR for this: #1521

@msmolcic-roko
Copy link

Did anyone actually manage to make this work?

@pank789 pank789 linked a pull request Oct 24, 2023 that will close this issue
@raman-m
Copy link
Member

raman-m commented Nov 30, 2023

@Sacrilege commented on Sep 23, 2021

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

@raman-m raman-m added accepted Bug or feature would be accepted as a PR or is being worked on feature A new feature 2023 Annual 2023 release and removed needs validation Issue has not been replicated or verified yet question Initially seen a question could become a new feature or bug or closed ;) labels Nov 30, 2023
@raman-m raman-m added this to the December'23 milestone Nov 30, 2023
@raman-m raman-m linked a pull request Nov 30, 2023 that will close this issue
@raman-m raman-m modified the milestones: Annual 2023, Summer'24 Jul 17, 2024
@raman-m raman-m modified the milestones: Summer'24, Annual 2023 Jul 17, 2024
@raman-m raman-m added the high High priority label Jul 17, 2024
@raman-m
Copy link
Member

raman-m commented Jul 17, 2024

@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.

@raman-m raman-m added Oct'24 October 2024 release and removed 2023 Annual 2023 release labels Oct 9, 2024
@raman-m raman-m modified the milestones: Annual 2023, October'24 Oct 9, 2024
@raman-m raman-m added Dec'24 December 2024 release and removed Oct'24 October 2024 release labels Oct 26, 2024
@raman-m raman-m modified the milestones: October'24, Autumn'24 Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted Bug or feature would be accepted as a PR or is being worked on Dec'24 December 2024 release feature A new feature high High priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.