Reactjs ASP Net内核和集成的Windows身份验证

考虑以下场景：

• 用户使用他们的凭据登录到他们的Windows计算机，这将授权他们使用AD
• ServiceX—现有API，只能通过集成Windows Auth访问

现在是否可以添加新的web应用程序服务NewService，其中包括：

• 新闻服务后端（ASP Net Core-可以自托管，也可以托管在IIS后面，与ServiceX位于同一域内）
• 新闻服务前端（反应）

在某种程度上，以下场景是可能的：

用户Alice登录到他们的Windows帐户

打开浏览器并导航到新闻服务的url

NewService应用程序获取当前用户的windows凭据，因此用户无需再次输入凭据，可以立即在新应用程序中以Alice身份开始工作

重要…而新闻服务后端（非前端）可以调用ServiceX模拟Alice

是4。可能的我不确定windows凭据如何在浏览器和应用程序之间传输，以及新闻服务后端是否可以使用它们来模拟用户

=============

澄清： 我们最感兴趣的是如何以调用第一个服务的域用户的名义调用另一个服务

用户（Alice）使用Windows身份验证向新闻服务后端发出请求（来自浏览器中的React应用程序）

NewService backend以Alice的名义向ServiceX发出请求

新闻服务后端与ServiceX位于不同的计算机上

我不确定的是：

• React应用程序（在浏览器中）能否将Windows用户标识（？SID？）传递到新闻服务后端，以及如何传递
• 如果是这样，那么新闻服务后端能否将Alice的身份传递给ServiceX，以便ServiceX认为Alice在打电话？怎么做

---

您描述的是自2002年以来的默认行为，但服务从未获得用户的凭据。它不需要它们。只要网站托管在IIS上，就可以在网站本身上指定Windows身份验证。即使不是，只要IIS被用作反向代理，它就可以处理身份验证。你是在问模拟而不是身份验证吗？是否使用客户端凭据在服务器上执行代码？大多数情况下，没有理由使用最终用户的凭据。您可以很容易地检查谁是登录用户，更可能是以下OpenID连接场景：@PanagiotisKanavos，但ServiceX（仅通过Windows身份验证访问）如何知道它可以完成NewService后端的请求。。。还是我遗漏了什么？您描述的是自2002年以来的默认行为，只是服务从未获得用户的凭据。它不需要它们。只要网站托管在IIS上，就可以在网站本身上指定Windows身份验证。即使不是，只要IIS被用作反向代理，它就可以处理身份验证。你是在问模拟而不是身份验证吗？是否使用客户端凭据在服务器上执行代码？大多数情况下，没有理由使用最终用户的凭据。您可以很容易地检查谁是登录用户，更可能是以下OpenID连接场景：@PanagiotisKanavos，但ServiceX（仅通过Windows身份验证访问）如何知道它可以完成NewService后端的请求。。。还是我遗漏了什么？