Search code examples
c#oauth-2.0restful-authenticationrestful-architectureidentityserver4

Identity Server(OAuth2) implementation with integration to legacy systems(Forms Auth, ADFS,AD)

We are currently building a RESTful API(.Net Core, IdentityServer 4, EF6). We have released an MVP version of it.

It also references a WCF service. This WCF service orchestrates all other calls to other internal (Legacy systems) and other integration components.

(Possibly wrong) Overview diagram of the implementation is as follows:

enter image description here

One of the main things we are stuck with is figuring out how to integrate different authentication and authorization systems using Identity Server...

Particularly internal service to service calls. Do we use the same IdentityServer to perform multiple functions?(public consumer authorisation & authentication AND internal service-to-service authorisation).

Traditionally we have used different WCF security configurations (Transport, TransportWithMessageCredentials...and so on), adding Forms, AD, ADFS and Service Accounts. We need to be sure we are making the right calls for making a reusable IdentiyServer implementation.

In short, Our challenge is how do you perform internal service authorization?

  1. Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?
  2. Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?
  3. Or do we even go further as to split and create a different identity server for each application use case?
Solution

  • Here are my thoughts on a solid implementation plan.

    1. Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?

      Reasons to have shared implementation:

      • Simpler Solution

      Reasons to have separate implementation:

      • Different security requirements for external vs. internal users/clients
      • External Outage wouldn't impact internal users/clients

      Recommendation: In the short term use an implementation that will service both with the goal to split them out into External and Internal focus areas.

    1. Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?

      Recommendation: Long term yes. See above as to why.

    1. Or do we even go further as to split and create a different identity server for each application use case?

      Recommendation: No, creating an separate identity server for each client/use case would be harder to manage in the long term. You would create separate clients for each application/scenario. (i.e. Mobile Client, MVC web site, Internal Server to Internal Server, External API/Service to Internal API/Service [Think of B2B interfaces])

    You will want to learn about the client types and how to allow extension grants, which is when a clients credentials to be used when a direct API call needs to call a secondary API as the user.