Use (o no use) OAuth para la comunicación interna de servicio a servicio en SOA

2

Somos un grupo de estudiantes que creamos una plataforma en línea para nuestra Universidad. Estamos modelando nuestra plataforma como un conjunto de servicios.

Por ejemplo, un servicio "A" puede almacenar solo información personal de los usuarios y exponer una API REST encima. Otro servicio "B" solo puede estar enviando correos electrónicos.

Una estructura rugosa se vería así:

AhoraqueremosutilizarOAuthparalaautenticaciónyautorización(SéqueOAuthesunmarcodeautorización,peroqueremoshacer aproximadamente qué google hace ).

Un escenario típico podría ser algo como:

  1. El usuario solicita la página web del servicio "A".
  2. El servicio "A" ve que el usuario no está autenticado, por lo que enviará una redirección al servidor de autenticación.
  3. El usuario ingresa sus credenciales y se otorga un token de acceso al servicio "A".

Ahora, el servicio "A" puede necesitar llamar a otro servicio "B". Tenga en cuenta que esta es una solicitud interna de servidor a servidor . Varios otros servicios pueden estar llamando al servicio "B".

Quiero asegurarme de que cuando se llame al servicio "B", solo los servicios permitidos puedan llamarlo. Por ejemplo, "A" tiene el derecho de llamar "B", pero "C" no lo hace. En otras palabras, quiero asegurar que solo las personas que llaman en la lista blanca para un servicio en particular puedan llamarlo .

Entonces, mi pregunta es, ¿es posible proteger las llamadas internas de servicio a servicio usando OAuth?

¿Se puede hacer de una manera más simple pero segura?

No quiero la delegación de token: es decir, no quiero que el primer token emitido para el servicio A se use en otro lugar. Se supone que si "A" está llamando a "B", entonces "A" tiene el derecho de hacerlo, incluso si no hay ningún usuario registrado.

Mi intento : (podría estar equivocado, corríjame) * El servidor de autenticación puede emitir clientIds y secretos de cliente para cada servicio. * Un servicio que quiere llamar a otro servicio se identifica con el servidor Auth usando clave y secreto. * Si se permite que el servicio llame al servicio de destino, el servidor de autenticación emite un token, de lo contrario, el servicio de devolución está prohibido.

Pero incluso en este caso, el servidor de autenticación está haciendo demasiado.

¿No puede cada servicio controlar lo que otros servicios pueden llamar?

Gracias.

    
pregunta Akshay Arora 05.10.2016 - 08:54
fuente

1 respuesta

3

Esto comenzó como un comentario, pero creció un poco para eso, así que lo moví a una 'respuesta'.

El paso que falta en las especificaciones de OAuth2.0 es la 'comunicación backend': la parte en la que el servidor de autorización y los diversos servicios acuerdan qué es un token válido y qué alcance está asociado con él. Estos 'detalles de implementación' quedan a la discreción del proveedor de servicios OAuth.

Además, su diagrama podría mejorarse si se ajusta más a la terminología OAuth2.0 (no estoy diciendo que haya hecho un mal trabajo, el diagrama es útil, pero podría ser más claro).

Su 'Usuario' en este caso es (presumiblemente) el Propietario del recurso . El 'Frontend' podría (supongo que aquí) ser una aplicación de una sola página, que se ejecuta dentro del User Agent .

Es el User Agent el que recibe el Access Token del Authorization Server , para acceder a los datos en nombre de Propietario del recurso .

En otras palabras, a su diagrama le falta la comunicación entre el "Usuario" y el "Servidor de autenticación".

Para el flujo de OAuth, tal vez el siguiente diagrama sea útil:

Figura1:flujodeOAuthparaclientes(confidenciales).

Pararesponderasupregunta:OAuthsetratadeladelegacióndeautorizacióndeunResourceOwneraalgúnservicioparaaccederalosdatosdeResourceOwnerensunombre.

Porlotanto,usarOAuthpuedenosertumejoropción.Sinembargo,noconozconingunasoluciónlistaparausarquerealmenteresuelvasuproblema(delegacióndederechosdeacceso,ennombredeunusuario).Puedeconsultar control de acceso basado en autorización (ZBAC) pero puede ser una exageración por lo que intenta lograr.

    
respondido por el Jacco 05.10.2016 - 11:07
fuente

Lea otras preguntas en las etiquetas