Identity Server(OAuth2)实现与遗留系统的集成(Forms Auth,ADFS,AD)

Question

我们目前正在构建RESTful API(.Net Core,IdentityServer 4,EF6).我们已经发布了它的MVP版本.

它还引用了WCF服务.此WCF服务协调对其他内部(旧系统)和其他集成组件的所有其他调用.

(可能是错误的)实现概述图如下:

我们坚持的主要事情之一是弄清楚如何使用Identity Server集成不同的身份验证和授权系统......

特别是服务电话的内部服务.我们是否使用相同的IdentityServer来执行多个功能？(公共消费者授权和认证以及内部服务到服务授权).

传统上,我们使用了不同的WCF安全配置(Transport,TransportWithMessageCredentials ......等),添加了Forms,AD,ADFS和Service Accounts.我们需要确保正在进行正确的调用以实现可重用的IdentiyServer实现.

简而言之,我们的挑战是如何执行内部服务授权？

1. 拥有一个处理面向公众的请求和内部(多跳)服务到服务授权的中央Identity Server实现是一种好习惯吗？
2. 您是否建议从处理面向公众的API请求的那些服务器中拆分并拥有单独的身份服务器以进行内部服务到服务授权？
3. 或者我们是否还要进一步拆分并为每个应用程序用例创建不同的身份服务器？

Answer 1

以下是我对可靠实施计划的想法。

1. 拥有一个中央身份服务器实现来处理面向公众的请求和内部（多跳）服务到服务授权是一个好习惯吗？

   共享实施的原因：

   • 更简单的解决方案

   单独实施的原因：

   • 外部与内部用户/客户端的不同安全要求
   • 外部中断不会影响内部用户/客户

   建议：短期内使用一种为两者提供服务的实现，目标是将它们分为外部和内部重点领域。

2. 您是否建议将用于内部服务到服务授权的身份服务器与处理面向公众的 API 请求的身份服务器分开并拥有单独的身份服务器？

   建议：长期是的。原因请参见上文。

3. 或者我们是否进一步为每个应用程序用例拆分并创建不同的身份服务器？

   建议：不，从长远来看，为每个客户端/用例创建单独的身份服务器将更难管理。您将为每个应用程序/场景创建单独的客户端。（即移动客户端、MVC 网站、内部服务器到内部服务器、外部 API/服务到内部 API/服务 [想想 B2B 接口]）

您将需要了解客户端类型以及如何允许扩展授权，即当直接 API 调用需要以用户身份调用辅助 API 时使用客户端凭据。