19

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?
tinonetic
  • 7,751
  • 11
  • 54
  • 79

3 Answers3

5

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.

aaronR
  • 1,557
  • 2
  • 16
  • 26
3

First off I would say you are going to have to bang your head on the wall a lot.

I think an ideal situation is where you only support one Identity Provider such as Active Directory. Microsoft would have you believe their solution is easy but it is not. That is why if you have to support a legacy Identity provider as well as a new system in parallel you will suffer more.

A secondary solution would be to keep the legacy Identity Provider system and implement the new API through it. I guess it must be a custom solution that is hosted on your own resources. That has the disadvantage to come with no built in capabilities and every new need must be built from scratch.

Honestly if you can isolate the legacy (or remove it) from your new system you will get huge benefits long term for maintenance and malleability.

I would look at code samples before making a decision. Better know deal breakers before spending weeks in any direction.

Simon Bourdeau
  • 429
  • 5
  • 18
  • Yes, it may be ideal to have one Identity Provider, but the real life situation(as it is in our case) is that there are multiple applications that are already running, each with their own form of authentication and authorization. Changing these applications is not feasible as they are running well and it will involve more time and resources...Integration is the only alternative with our scenario, making use of façades and adapters – tinonetic Sep 11 '17 at 07:29
  • Yes sometimes we have no flexibility I understand that. That comes with a cost however as you will find out. aaronR's answer makes more sense then. – Simon Bourdeau Sep 11 '17 at 16:52
2

Here's my point of view for above problem

  1. A Separate Identity Server for internal service

  2. There are more pros in separation of identity server for internal service i.e.

    Outage & Configuration changes in future won't affect consumers. For Testing Purpose, a separate identity server is best if you are trying to support legacy applications

    New Server has long term benefits & Security Enhancements.

Karan
  • 53
  • 3