集成到旧系统的身份服务器(OAuth2)实施(Forms Auth、ADFS、AD)
我们目前正在构建一个核心接口(.Net RESTful，IdentityServer 4，EF6)。我们已经发布了它的MVP版本。
它还引用了WCF服务。此WCF服务编排对其他内部(旧系统)和其他集成组件的所有其他调用。
(可能是错误的)实现的概览图如下：
我们遇到的主要问题之一是弄清楚如何使用Identity Server集成不同的身份验证和授权系统……
特别是内部服务到服务调用。我们是否使用same IdentityServer来执行多项功能？(公共消费者授权和身份验证以及内部服务到服务授权)。
传统上，我们使用不同的WCF安全配置(传输、TransportWithMessageCredentials...and等)，添加表单、AD、ADFS和服务帐户。我们需要确保我们做出了正确的调用，以实现可重用的IdentiyServer实现。
简而言之，我们的挑战是如何执行内部服务授权？
- 具有同时处理面向公众的请求和内部(多跃点)服务到服务authorization?
- Do的中央身份服务器实现是一种好的做法吗?您建议将内部服务到服务授权的身份服务器与处理面向公众的
- 请求的身份服务器分开，并使其与处理面向公众的
- 请求的身份服务器分开？
- 或者我们是否更进一步，为每个应用程序用例拆分并创建不同的身份服务器？
回答 3
Stack Overflow用户
发布于 2017-09-08 12:53:27
以下是我对一个可靠的实施计划的想法。
- 有一个中央身份服务器实现来处理面向公众的请求和内部(多跃点)服务到服务授权，这是不是一种好的做法？
共享implementation:的理由
- Simpler Solution使用单独实现的原因：
- Different security requirements for external vs. internal users/clients
- External Outage wouldn't impact internal users/clientsRecommendation：在短期内使用的实现将服务于两者，目标是将它们分为外部和内部重点领域。
您是否建议将内部服务到服务授权的身份服务器与处理面向公众的
- 请求的身份服务器分开，并使用单独的身份服务器？Recommendation：长期而言是的。请参阅上面的原因。
- ，或者我们是否更进一步，为每个应用程序用例拆分并创建不同的身份服务器？Recommendation：否，从长远来看，为每个客户端/用例创建单独的身份服务器将更难管理。您将为每个应用程序/场景创建单独的客户端。(即移动客户端、MVC网站、内部服务器到内部服务器、外部应用程序接口/服务到内部应用程序接口/服务考虑B2B接口)
您将希望了解client types以及如何允许extension grants，即当直接API调用需要以用户身份调用辅助API时使用客户端凭据。
Stack Overflow用户
发布于 2017-09-07 02:22:13
首先，我要说的是，你得经常用头撞墙。
我认为理想的情况是你只支持一个身份提供者，比如Active Directory。微软会让你相信他们的解决方案很简单，但事实并非如此。这就是为什么如果你必须同时支持一个旧的身份提供者和一个新的系统，你会遭受更多的痛苦。
次要的解决方案是保留旧的身份提供者系统，并通过它实现新的API。我猜它一定是一个自定义的解决方案，托管在您自己的资源上。这有一个缺点，那就是没有内置的功能，每个新的需求都必须从头开始构建。
老实说，如果你能从你的新系统中隔离(或移除)遗留的东西，那么从长远来看，你将在维护和延展性方面获得巨大的好处。
在做决定之前，我会先看看code samples。在花几周时间在任何方向之前，最好了解交易的破坏因素。
Stack Overflow用户
发布于 2017-09-08 20:08:13
以下是我对上述问题的观点
- 用于内部service
- There的独立身份服务器更有利于将身份服务器分离用于内部服务，即
Outage & Configuration changes未来不会影响消费者。出于测试目的，如果要尝试支持旧版应用程序，则最好使用单独的身份服务器
新的服务器有长期的好处和安全性Enhancements.
https://stackoverflow.com/questions/46001211
复制相似问题