Asegurar una API multiusuario con SSO y diferentes roles por arrendatario

3

Estoy trabajando en el desarrollo de una API REST que será utilizada por los clientes de primera parte que desarrollamos, y los clientes de terceros en el futuro. Los clientes principales incluyen una aplicación del lado del cliente SPA y programas que se ejecutan en las PC clientes (no puede garantizar la seguridad de los secretos).

Además, esta API es pseudo-multitenant. Tenemos varios inquilinos, y cada inquilino puede tener una o más instancias activas en la API, cada una con su propio conjunto de roles de seguridad, cada uno con diferentes permisos. Sin embargo, todos estos datos se almacenan en la misma base de datos, y queremos que los usuarios puedan cambiar la instancia en la que están trabajando (tanto in-tenant como out-of-tenant). El inicio de sesión PUEDE permitirse el uso de proveedores externos (Facebook / Google / etc). Además, su inicio de sesión debe permitirles acceder a las otras instancias sin volver a autenticarse.

Me estoy confundiendo un poco sobre cómo debo implementar la lógica de autenticación / autorización dada la naturaleza de múltiples inquilinos y múltiples roles de la API. Lo que estoy pensando que es la ruta correcta es implementar la autenticación de OpenID Connect en la API, y luego OAuth para delegar el acceso a las instancias específicas que el usuario está intentando. Mi confusión entra en juego cuando intento determinar qué tokens se deben usar en dónde. Queremos que nuestros usuarios puedan iniciar sesión en el SPA y seguir cambiando su instancia.

He visto información sobre cómo proteger las API de REST multitenant / multidatabase, pero las funciones parecen ser coherentes, por lo que no puedo extrapolar el manejo a una base de datos con varias funciones.

Estas son mis preguntas:

  • ¿Es correcto usar OpenID Connect y OAuth2 dada esta información?
  • Parece que OpenID Connect permite anunciar los ámbitos que desea delegar. ¿Cómo se manejaría esto con roles indeterminados hasta después de la autenticación y cuando se conoce a su inquilino?
  • ¿Es correcto delegar los permisos individuales a través de OAuth (lo que quiero hacer), o debería OAuth simplemente delegar sus roles asignados por instancia, y la aplicación debe buscar los permisos?
  • ¿Debería haber dos tokens separados, uno para la autenticación general y otro para la autorización por instancia? ¿Cuál sería el estándar para pasar estos a la API. Actualmente estamos usando JWT y un encabezado del Portador de Autorización. Me gusta la simplicidad de una ficha, pero si es necesario ajustarla y modificarla, podemos hacerlo.

He estado buscando artículos durante la última semana o dos sobre esto, pero no he encontrado nada que ayude a aclarar qué tipo de flujo sería mejor para mi situación y cómo manejo la variabilidad de una instancia a otra. Si crees que me he perdido un artículo, siéntete libre de agregarlo a esto como un comentario y lo revisaré también.

    
pregunta tostringtheory 28.08.2017 - 17:31
fuente

1 respuesta

2

No soy un programador, pero he revisado una organización que parece hacer algo similar. Así es como lo hacen ...

El cliente AngularJS se autentica con una API de seguridad de la aplicación que tenemos a través de OAuth. El sistema que aloja la API luego pasa la autenticación y solicita la autorización de un segundo sistema. El segundo sistema devuelve el token authZ, el nombre de usuario y las reclamaciones al sistema API de seguridad. La API de seguridad llama a un sistema de administrador de tokens que crea un JWT y lo devuelve al sistema de API de seguridad. Finalmente, la API de seguridad devuelve el JWT codificado al cliente AngularJS.

Una llamada individual pasa del cliente AngularJS a la API de la aplicación real, proporcionando el token. El sistema API de la aplicación le da el token al administrador de token para su validación. Si es válido, la API devuelve datos (o se arroja en tokens no válidos o caducados).

Para la renovación, el cliente AngularJS se pone en contacto nuevamente con la API de seguridad, que se comunica con el sistema de token authZ, devolviendo el token renovado al sistema de la API de seguridad, que lo envía al administrador de token para la creación de un nuevo JWT, que la API de seguridad Vuelve al cliente.

Al cambiar de arrendatario, realiza una llamada de solicitud de transferencia de token authZ a la API de seguridad que llega hasta el servidor de token authZ, se crea un token authz nuevo y se envía de vuelta a la API de seguridad junto con el nombre de usuario y los roles, solicita un JWT con eso, y una vez devuelto, lo pasa al cliente.

Para responder más directamente a tus preguntas ...

  • Parece correcto usar OAuth y OIDC
  • No sé acerca de la publicidad de alcance.
  • Estoy en seguridad, por lo que soy un fanático del control de acceso basado en roles para todo. :-D Así que diría que la aplicación realice las búsquedas de permisos individuales de los roles incrustados en el token.
  • Dos tokens separados parecen ser la forma en que esta organización lo trata. Uno, que parece funcionar como identidad e identificación de sesión. El segundo es el JWT que incluye ese primer token y los roles / reclamos para el inquilino actual.
respondido por el Cliff 06.09.2017 - 20:08
fuente

Lea otras preguntas en las etiquetas