Estoy escribiendo una aplicación que será el backend de un sitio web react. El sitio web debe ser utilizado por nuestros clientes, pero controlaremos completamente los permisos del usuario. Hemos decidido utilizar Azure AD para proteger las solicitudes, pero también expondremos la API para que los usuarios finales la utilicen directamente si así lo desean.

Según tengo entendido, en Azure AD tendré que crear una aplicación que permita la autenticación implícita basada en web (para el sitio de reacción), así como una aplicación nativa que permitirá que una aplicación basada en dameon se autentique en la API.

Creo que esto significa que tendré dos identificadores de audiencia en mi aplicación.

Estoy tratando de obtener reclamos para incluir grupos, y puedo ver si edito los metadatos de ambas aplicaciones en Azure AD para incluir "groupMembershipClaims": "SecurityGroup" Puedo obtener reclamos con los ID de grupo, pero sin nombres.

Creo que también puedo usar appRoles para establecer los roles que usa la aplicación, pero aún no lo he logrado como reclamos en el JWT, pero asumo que se puede hacer, sin embargo, necesitaría para configurar los roles en cada aplicación, luego agregue el usuario dos veces, lo cual no es realmente ideal. También creo que debido a que mi aplicación tiene múltiples usuarios, los usuarios externos podrían usar esto para establecer sus propios permisos, que no es lo que quiero hacer.

Lo siento, estoy totalmente perdido y la documentación es más que confusa dada la frecuencia con la que esto parece cambiar.

TLDR: ¿Necesito dos aplicaciones configuradas en azure ad? Si es así, ¿cuál es la mejor manera de establecer permisos (reclamos)? ¿También oAuth 2 es la opción correcta aquí, o debería mirar la identificación abierta?

0
Ross Dargan 20 feb. 2018 a las 17:32

2 respuestas

La mejor respuesta

De inmediato tengo que arreglar un malentendido. Las aplicaciones de demonio generalmente deben registrarse como Web / API, es decir, publicClient: false. Eso es porque una aplicación nativa no puede tener secretos de cliente. Por supuesto, entonces el demonio no puede ejecutarse en el dispositivo de un usuario. Ya que eso es lo que es una aplicación nativa. Una aplicación que se ejecuta en el dispositivo de un usuario.

Creo que esto significa que tendré dos identificadores de audiencia en mi aplicación.

Tendrá dos aplicaciones , al menos. Si lo desea, el back-end y el frente de React pueden compartir una aplicación (con el flujo implícito habilitado). Y el demonio necesitará otro registro.

Estoy tratando de obtener reclamos para incluir grupos, y puedo ver si edito los metadatos de ambas aplicaciones en Azure AD para incluir "groupMembershipClaims": "SecurityGroup". Puedo obtener reclamos con los ID de grupo, pero sin nombres.

Sí, solo se incluyen los identificadores. Si necesita nombres, vaya a Graph API para obtenerlos. Pero, ¿por qué los necesitas? ¿Para mostrar? De lo contrario, debe utilizar los identificadores para configurar los permisos. Los nombres siempre cambian y luego su código se rompe.

Creo que también puedo usar appRoles para establecer roles que usa la aplicación, pero todavía tengo que conseguir que eso se transmita como reclamos en el JWT, pero supongo que se puede hacer, sin embargo, necesitaría configurar los roles en cada aplicación, luego agregue el usuario dos veces, lo que no es realmente ideal. También creo que debido a que mi aplicación tiene múltiples usuarios, los usuarios externos podrían usar esto para establecer sus propios permisos, que no es lo que quiero hacer.

Sus pensamientos sobre escenarios de múltiples inquilinos son correctos. Sin embargo, si deseaba implementarlos, hice un artículo al respecto: https://joonasw.net/view/defining-permissions-and-roles-in-aad.

Sin embargo, ¿por qué necesitarías configurar los roles en múltiples aplicaciones? ¿No se aplicarían solo en la aplicación web? Si la aplicación nativa es un demonio, no hay ningún usuario.

En general, puedo ver tu problema. Tienes personas de otras organizaciones que quieren acceder a tu aplicación, pero quieres controlar sus derechos de acceso.

Honestamente, la mejor manera podría ser convertir la aplicación en un inquilino único en algún inquilino que usted controle. Luego invite a los usuarios externos allí como invitados (hay una API para esto). Luego, puede asignarles roles usando grupos o appRoles.

Si entendí mal algo, deje un comentario y arreglaré mi respuesta.

1
juunas 20 feb. 2018 a las 17:47

Azure AD es, por supuesto, un sistema poderoso, aunque también encuentro confusos los aspectos de OAuth ya que estos aspectos están muy mezclados:

  • OAuth 2.0 basado en estándares y Open Id Connect
  • Comportamiento específico del proveedor de Microsoft

RESPUESTAS RELACIONADAS CON EL PAPEL

Esta no es un área sobre la que sepa mucho, Juunas parece un gran tipo para ayudarte con esto.

NORMAS DE OAUTH Y AZURE

Luché con esto hace un tiempo para un blog de OAuth basado en tutoriales que estoy escribiendo. Quizás algunas de las cosas que aprendí y escribí te sean útiles.

MUESTRA DE CÓDIGO API Y AZURE SPA

Mi ejemplo muestra cómo usar el flujo implícito en un SPA para iniciar la sesión del usuario a través de Azure AD, luego cómo validar los tokens recibidos en una API personalizada:

No estoy seguro de cuánto de esto es relevante para su caso de uso, pero espero que ayude un poco en el lado tecnológico de las cosas ...

0
Gary Archer 22 feb. 2018 a las 09:14