Pros y contras de tener dos proveedores de identidad

Navega tus respuestas
4

Mi empresa tiene aplicaciones en la nube e intranet. Además, tenemos varias funciones, como empleados, clientes, socios, etc. Nos gustaría una federación de ID entre los servicios alojados en la nube pública y las aplicaciones internas. Los siguientes escenarios son posibles

  1. Empleado que accede a los servicios en la nube desde la intranet
  2. Empleados, clientes, socios que acceden a servicios en la nube desde Internet
  3. Servicios alojados en la nube que acceden a servicios de datos alojados internamente en una red corporativa
  4. Empleados, clientes, socios que acceden a aplicaciones / servicios web alojados internamente en una red corporativa desde Internet.
  5. Empleados, clientes, socios que acceden a aplicaciones / servicios web alojados internamente en la red corporativa desde la intranet.

Siempre que se acceda desde Internet a aplicaciones alojadas internamente o aplicaciones basadas en la nube, el SSO debe crearse mediante la autenticación multifactor, pero si se accede a las mismas aplicaciones desde la intranet, cualquiera de las dos es la contraseña de usuario o si el usuario es un empleado. El SSO de la empresa debe estar federado a servicios / aplicaciones basados en la nube.

Estamos debatiendo si existen ventajas o desventajas de tener dos proveedores de Identity, uno desplegado en DMZ y otro en la red interna. El que está en DMZ impondrá el acceso desde la intranet a los servicios basados en la nube o los usuarios que accedan a los servicios basados en la nube desde Internet se federarán a este IDP. Además, los usuarios de Internet que intentan acceder a las aplicaciones internas obtendrán la autenticación de múltiples factores de este IDP en dmz. El IDP dentro de la red interna se usa solo para los empleados que acceden a las aplicaciones de intranet.

Mi pregunta es si el IDP un poco anterior es una forma estándar de permitir el acceso. ¿Cuál es el daño de tener un solo IDP?

    
pregunta Jimm 17.08.2013 - 19:52
fuente

1 respuesta

1

La forma más fácil que creo es identificar un único proveedor de identidad (autenticación / autorización) como la "Fuente autorizada". Esto almacenará toda su información de identidad en todas sus aplicaciones y servicios.

Esto proporcionará el registro maestro mediante el cual podrá proporcionar autenticación y autorización para todos y cada uno de los usuarios. Esta única fuente autorizada debería poder enviar datos a la zona DMZ para proporcionar la información a las otras aplicaciones que están en la nube. Esto garantiza que las cuentas no puedan ser reanimadas debido a que alguien habilite una cuenta dentro de la DMZ.

Esto también ayuda mucho cuando aprovisiona y desaprovisiona las identidades, ya que solo tendrá que eliminar al usuario de un registro en lugar de desactivarlo en dos o tres fuentes diferentes. (Crea procesos desesperados y causa debilidades en su proceso IdM). 

|   Cloud Infrastructure  |
---------------------------
|          Internet    ^  |
|                      |  |
---------------------------
|    DMZ               |  | <= External copy of authoritative source (read only from external)
|                      |  |
--------------------------|
| Internal - Authoritative| <= Authoritative Source (HR records/etc) reside here.
    
respondido por el m3r1n 17.07.2014 - 21:26
fuente

Lea otras preguntas en las etiquetas

Autenticar usuarios a través de Google usando solo un token de acceso OAuth2 Asegurar un almacenamiento conectado a la red en Internet