使用单个身份验证层验证多个 WebAPI答案

【问题标题】：Authenticating multiple WebAPIs with a single Identity Authentication layer使用单个身份验证层验证多个 WebAPI
【发布时间】：2015-03-28 00:42:09
【问题描述】：

我一直在努力解决如何为我们当前/未来的 WebAPI 简化 WebAPI/身份验证。我是新手，但我会尽力解释。我们从单个 WebAPI 开始并设置 ASP.Net Identity 来处理身份验证等。然后我们再设置一个，很快就30了。

这里的问题很明显 - 对于每个新的 WebAPI，我们都必须插入另一个 MS 身份授权层。在某些情况下，只有一个庞大的 WebAPI 就可以工作，但在这种情况下，它们是完全独立的产品（加上其糟糕的设计）。

所以我们想拍摄这样的东西：

但我很难弄清楚每个 WebAPI 将如何获取用户信息，以便我可以检查角色等。

我已经阅读了许多关于 WebAPI 身份验证的帖子，例如：this this 和 this，但我发现的所有内容似乎都与保护单个 WebAPI 有关，我们已经知道如何做到这一点。感觉我们需要的是一种用于 WebAPI 的 SSO 方法。似乎我们需要类似外部身份验证方法（如 Facebook、Twitter 等）但使用我们自己的后端数据库 - 我只是不知道正确的术语。

所以我正在向专家寻求帮助，让我朝着正确的方向前进：

通常的做法是让每个 WebAPI 都有自己的身份验证/授权层，每个都指向同一个数据库吗？
WebAPI/Identity 中是否已经内置了单一身份验证层概念，还是必须从头开始？
我们应该使用Authentication Filter 吗？

我可以在幕后破解所有问题，但感觉好像我缺少一个明显的答案。

是否有一种内置方法可以在每个 WebAPI 和身份验证 API 之间设置“信任”以执行以下操作：

这是我们目前前进的方向：

如果我能在正确的方向上获得总体推动，我会很高兴作为一拳。我只是不想重新发明轮子。

哦，在我忘记之前，我们在 IIS 上使用 asp.net 4.5、WebAPI 2、Identity 2

感谢您的任何指点。

【问题讨论】：

标签： c# asp.net authentication asp.net-web-api asp.net-web-api2

【解决方案1】：

不要给出过于简单的答案，但您不能只是构建一个 API 作为围绕其他 API 的时尚。顶级 API 处理所有授权，然后将调用转发到您的其他 API。我不是建筑师，但我会这样做。

【讨论】：

是的，你是对的。这种方法是我们在上面提到的“all in one WebAPI”中所考虑的，但是 Facade 必须了解每个 WebAPI 中的每个方法。如果我们想建立一个只有少数 WebAPI 设置的简约服务器，则需要更改代码。我希望这是有道理的，但我确实要感谢你提出这个问题，因为我在最初的陈述中并不是很清楚。 ;)
我可能还不清楚的另一件事是，每个 WebAPI 当前都包含数百个端点，因此为所有端点设置外观将是一项艰巨的任务（除非我错过了这）并且会随着我们添加新的 API 而恶化。除非有办法让他们盲目通过？ [叹气] 不确定。但这实际上倾向于使用身份验证过滤器——它并不关心你的要求，它只是完成它的工作并将请求传递到下线。 谢谢威尔！

【解决方案2】：

您正在寻找的是您自己的 Web api 的联合身份，这是 Thinktecture's Identity Server 旨在解决的问题。 documentation 可能是最好的起点

【讨论】：

是的，我今天也读到了这一点，但在我上面的请求中没有提及。我退缩了，因为我从其他人那里读到一些 cmets 说你不想那样做。但是 - 根据您的 SO 分数和推荐，听起来我需要自己研究和研究它。这是我今晚的作业！谢谢拉斯
@PRB - 不用担心。联合身份、基于声明的身份、WS-Federation、SAML、STS 等可以成为导航的思维领域。我已经看到 IdentityServer 成功地用于为许多 Web api 提供基于声明的身份。我不会称自己为安全专家，因此只能建议您进行研究并得出自己的结论。我还建议下载基于声明的身份和访问控制的 PDF - msdn.microsoft.com/en-us/library/ff423674.aspx