title: Identity Server(OAuth2) implementation with integration to legacy systems(Forms Auth, ADFS,AD)
body: <p>We are currently building a RESTful API(.Net Core, <a href="https://github.com/IdentityServer/IdentityServer4" rel="noreferrer">IdentityServer 4</a>, EF6). We have released an MVP version of it.</p>
  
  <p>It  also references a WCF service. This WCF service orchestrates all other calls to other internal (Legacy systems) and other integration components.</p>
  
  <p>(Possibly wrong) Overview diagram  of the implementation is as follows:</p>
  
  <p><a href="https://i.stack.imgur.com/DQM9I.png" rel="noreferrer"><img src="https://i.stack.imgur.com/DQM9I.png" alt="enter image description here"></a></p>
  
  <p>One of the main things we are stuck with is figuring out <strong>how</strong> to integrate different authentication and authorization systems using Identity Server...</p>
  
  <p>Particularly <strong>internal service to service calls</strong>. Do we use the <strong>same IdentityServer</strong> to perform <strong>multiple functions?</strong>(public consumer authorisation &amp; authentication AND internal service-to-service authorisation).</p>
  
  <p>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.</p>
  
  <p><strong>In short, Our challenge is how do you perform internal service authorization?</strong></p>
  
  <ol>
  <li>Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?</li>
  <li>Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?</li>
  <li>Or do we even go further as to split and create a different identity server for each application use case? </li>
  </ol>