este problema se puede abordar de diversas maneras, pero nosotros te damos la respuesta más completa para nosotros.
Solución:
Cuando escribe una aplicación como desarrollador, la registrará en un inquilino determinado y especificará sus propiedades. Esto sucede en la hoja Registro de la aplicación en Azure AD. Me atreveré a hacer una analogía diciendo que la aplicación es como una “clase” en lenguajes orientados a objetos (con algunos static propiedades, que serán comunes a todas las instancias)
Al registrar la aplicación, en ese inquilino dado, si usa el portal, esto también creó automáticamente una entidad de servicio para esta aplicación, que puede encontrar en la hoja “Aplicaciones empresariales” del portal de Azure. Para continuar con mi analogía, el portal crea una especie de instancia de esa clase. Esta entidad de servicio contiene información relacionada tanto con la aplicación como con los inquilinos y sus usuarios. Por ejemplo, contiene la actividad de los usuarios, lo que han dado su consentimiento en particular.
Ahora bien, si durante el registro de la aplicación / administración de la aplicación, decide que su aplicación es “multiinquilino”, cuando se acceda a la aplicación en otros inquilinos, se creará otra entidad de servicio (recuerde esta instancia) en ese inquilino.
Por cierto, vaya a la nueva hoja Registro de aplicaciones (Vista previa) en el portal azure, cuando crea una aplicación, ahora puede ver bien agrupadas por categorías todas las propiedades de la aplicación (todas las propiedades que son comunes a todas las entidades de servicio ). Ahora, si, en la pestaña “Descripción general” de la aplicación, hace clic en el enlace “Aplicación administrada en el directorio local”, llegará a la entidad de servicio correspondiente en el mismo inquilino (donde verá qué usuarios han accedido al aplicación, cuándo, dónde puede otorgar el consentimiento de administrador, si es administrador de inquilinos, y ver la actividad y los registros de auditoría)
De hecho, esto es confuso y usted no es el único que se siente así. Supongo que toda esta aplicación / entidad de servicio está diseñada desde la perspectiva de las aplicaciones web, que se pueden escalar en varios inquilinos de Azure AD. Para alguien que solo quiere crear pequeños scripts que se conecten a los servicios de Azure, comprender todo esto es demasiado. Desafortunadamente, no hay forma de evitarlo. Azure Portal también es un poco confuso para esta parte, solo comenzó a tener algún sentido cuando usé la CLI de Azure para ello.
Para acceder a los recursos de Azure mediante programación, debemos usar las credenciales de entidad de servicio. Service Principal es en realidad una instancia de aplicación, por lo que primero debemos crear una Aplicación (Registro de Aplicación). Si se agrega el registro de la aplicación desde el portal, la entidad de servicio se crea automáticamente. Con la CLI de Azure, la creación de una aplicación y una entidad de servicio son dos pasos distintos.
La parte extraña es que las credenciales deben obtenerse de la aplicación (registros de aplicaciones -> seleccionar aplicación -> certificados y secretos). Mientras que la asignación de roles para el Director de servicio debe realizarse desde Suscripciones (seleccione suscripción -> Control de acceso (IAM) -> Asignaciones de roles). El mismo proceso con CLI tiene más sentido.
Uso de la CLI de Azure
- Registrarse / crear aplicación
$ az ad app create --display-name "displayName"
- Crear una entidad de servicio para la aplicación que acaba de crear
$ az ad sp create --id "applicationId"
- Establecer las credenciales de la aplicación
$ az ad app credential reset --credential-description "some_description" --id "applicationId"
O
$ az ad sp credential reset --credential-description "some_description" --name "applicationDisplayName" --append
- Asigne roles a la entidad de servicio para acceder a los recursos en Azure.
$ az role assignment create --assignee "service principal object id/ApplicationId" --role role_name
Y si no le importan todas estas cosas de la entidad de servicio / aplicación y solo desea utilizar la entidad de servicio para acceder a los recursos de Azure, hay un atajo.
$ az ad sp create-for-rbac --name "service_principal_name"
Esto creará la aplicación, el director del servicio, establecerá las credenciales en la aplicación, asignará el rol de colaborador al director del servicio e imprimirá las credenciales.
Dado que el nombre de la aplicación (en los registros de aplicaciones) y el principal de servicio (empresa / todas las aplicaciones) es el mismo, debemos mirar detenidamente la identificación del objeto y la identificación de la aplicación para averiguar cuál es cuál. Además de eso, los directores de servicio se enumeran como Aplicaciones empresariales / Todas las aplicaciones en Azure Portal.
‘Aplicaciones empresariales’ es solo una categoría de Principal de servicio que satisface dos condiciones.
- El director del servicio y el registro de la aplicación deben estar en el mismo inquilino.
- Service Principal debe tener la etiqueta ‘WindowsAzureActiveDirectoryIntegratedApp’. Si esta etiqueta se elimina de Service Principal, no se mostrará en Aplicaciones empresariales, pero seguirá apareciendo en “Todas las aplicaciones”. (¡¡No lo intentes en producción !!)
Tenga en cuenta que los principales de servicio creados a partir de cli no aparecían en ‘Aplicaciones empresariales’ y tuve que agregar la etiqueta manualmente.
$ az ad sp update --id "service_principal_object_id" --add tags WindowsAzureActiveDirectoryIntegratedApp
Aquí puedes ver las comentarios y valoraciones de los lectores
Nos puedes auxiliar nuestra publicación exponiendo un comentario y valorándolo te damos las gracias.