c# - ejemplos - Implementación de Identity Server(OAuth2) con integración a sistemas heredados(Forms Auth, ADFS, AD)

sistemas heredados ejemplos

Question

Actualmente estamos construyendo una API REST (.Net Core, IdentityServer 4 , EF6). Hemos lanzado una versión de MVP de la misma.

También hace referencia a un servicio WCF. Este servicio WCF organiza todas las demás llamadas a otros componentes internos (sistemas heredados) y otros componentes de integración.

(Posiblemente incorrecto) El diagrama general de la implementación es el siguiente:

Una de las principales cosas con las que estamos atrapados es descubrir cómo integrar diferentes sistemas de autenticación y autorización utilizando Identity Server ...

Particularmente servicio interno a llamadas de servicio . ¿Usamos el mismo IdentityServer para realizar múltiples funciones? (autorización y autenticación públicas del consumidor Y autorización interna de servicio a servicio).

Tradicionalmente, hemos utilizado diferentes configuraciones de seguridad WCF (Transport, TransportWithMessageCredentials ... y así sucesivamente), agregando formularios, AD, ADFS y cuentas de servicio. Necesitamos estar seguros de que estamos haciendo las llamadas correctas para hacer una implementación reutilizable de IdentiyServer.

En resumen, nuestro desafío es cómo realizar la autorización de servicio interno.

1. ¿Es una buena práctica tener una implementación central de Identity Server que maneje tanto las solicitudes públicas como la autorización interna (multihop) de servicio a servicio?
2. ¿Recomienda dividir y tener servidores de identidad separados para la autorización interna de servicio a servicio de aquellos que manejan las solicitudes de API de cara al público?
3. ¿O incluso vamos más allá para dividir y crear un servidor de identidad diferente para cada caso de uso de la aplicación?

Answer 1

Aquí está mi punto de vista para el problema anterior

1. Un servidor de identidad separado para el servicio interno

2. Hay más ventajas en la separación del servidor de identidad para el servicio interno, es decir

   Los cambios en la configuración y la interrupción en el futuro no afectarán a los consumidores. Para propósitos de prueba, un servidor de identidad separado es mejor si está tratando de admitir aplicaciones heredadas

   Nuevo servidor tiene beneficios a largo plazo y mejoras de seguridad.

Answer 2

Aquí están mis pensamientos sobre un plan de implementación sólido.

1. ¿Es una buena práctica tener una implementación central de Identity Server que maneje tanto las solicitudes públicas como la autorización interna (multihop) de servicio a servicio?

   Razones para tener implementación compartida:

   • Solución más sencilla

   Razones para tener una implementación separada:

   • Diferentes requisitos de seguridad para usuarios / clientes externos vs. internos
   • La interrupción externa no afectaría a los usuarios / clientes internos

   Recomendación : en el corto plazo, use una implementación que sirva para el objetivo de dividirlos en áreas de enfoque externas e internas.

2. ¿Recomienda dividir y tener servidores de identidad separados para la autorización interna de servicio a servicio de aquellos que manejan las solicitudes de API de cara al público?

   Recomendación : a largo plazo sí. Ver más arriba en cuanto a por qué.

3. ¿O incluso vamos más allá para dividir y crear un servidor de identidad diferente para cada caso de uso de la aplicación?

   Recomendación : No, crear un servidor de identidad separado para cada cliente / caso de uso sería más difícil de administrar a largo plazo. Usted crearía clientes separados para cada aplicación / escenario. (es decir, Cliente móvil, sitio web de MVC, Servidor interno a servidor interno, API externa / Servicio a API interna / Servicio [Piense en las interfaces B2B])

Querrá aprender sobre los tipos de clientes y cómo permitir concesiones de extensión , que es cuando se usan las credenciales de los clientes cuando una llamada directa a la API necesita llamar a una API secundaria como usuario.

Answer 3

En primer lugar, diría que vas a tener que golpearte mucho la cabeza contra la pared.

Creo que una situación ideal es donde solo se admite un proveedor de identidad, como Active Directory . Microsoft le haría creer que su solución es fácil, pero no lo es. Por eso, si tiene que admitir un proveedor de Identidad heredado, así como un nuevo sistema en paralelo, sufrirá más.

Una solución secundaria sería mantener el sistema heredado del proveedor de identidades e implementar la nueva API a través de él. Supongo que debe ser una solución personalizada alojada en sus propios recursos. Eso tiene la desventaja de no contar con capacidades integradas y cada nueva necesidad debe crearse desde cero.

Honestamente, si puede aislar el legado (o eliminarlo) de su nuevo sistema, obtendrá enormes beneficios a largo plazo para el mantenimiento y la maleabilidad.

Me gustaría ver ejemplos de código antes de tomar una decisión. Es mejor que sepas a los que rompen los tratos antes de pasar semanas en cualquier dirección.