Compartir a través de


Configuración de la autenticación de aplicaciones para Microsoft Planetary Computer Pro

En este artículo se proporcionan instrucciones paso a paso para que los desarrolladores y administradores configuren la autenticación segura de aplicaciones y el acceso a Microsoft Planetary Computer Pro. Al aplicar el identificador de Entra de Microsoft e identidades administradas, las aplicaciones se pueden autenticar sin problemas sin necesidad de administrar credenciales, lo que garantiza una interacción segura con los recursos de Planetary Computer Pro. Tanto si la aplicación se ejecuta en Azure como en otros entornos, en esta guía se describen las configuraciones necesarias, incluido el control de acceso basado en rol (RBAC) y la adquisición de tokens, para habilitar el acceso seguro.

Nota:

Para las aplicaciones que utilizan Azure AD B2C o Id. externa de Microsoft Entra y que admiten características como proveedores de identidad social, las aplicaciones deben seguir utilizando estas soluciones de identidad para el tráfico de autenticación proxy, ya que Planetary Computer Pro no admite alternativas a la autenticación de Microsoft Entra ID.

Opciones y recomendaciones de autenticación

En la tabla siguiente se resume el enfoque de autenticación recomendado en función de dónde se ejecuta la aplicación y cómo accede a los recursos:

Entorno de hospedaje de aplicaciones Tipo de acceso requerido Tipo de identidad recomendado Explanation
Ejecución en Azure (VM, App Service, Functions, Container Apps, etc.) App-Only (la aplicación actúa como sí misma) Identidad administrada (recomendada por el usuario) Seguridad y manejabilidad: Elimina la necesidad de almacenar y administrar credenciales (secretos o certificados) en código o configuración. Azure controla automáticamente la rotación de credenciales. Se prefiere el uso compartido por el usuario entre varios recursos.
Ejecución en Azure (VM, App Service, Functions, Container Apps, etc.) Delegado (la aplicación actúa en nombre de un usuario) Identidad administrada (recomendada por el usuario) Aprovecha la integración de Azure: Combina las ventajas de seguridad de la identidad administrada para la propia aplicación con flujos de autenticación de usuario estándar. Simplifica la configuración de la infraestructura en Azure.
Ejecución fuera de Azure (local, otra nube, máquina para desarrolladores) App-Only (la aplicación actúa como sí misma) Principal del servicio Estándar para aplicaciones externas: Método establecido para que las aplicaciones que no son de Azure se autentiquen con el identificador de Microsoft Entra. Requiere administrar credenciales (secretos o certificados) de forma segura.
Ejecución fuera de Azure (local, otra nube, máquina para desarrolladores) Delegado (la aplicación actúa en nombre de un usuario) Principal del servicio Estándar para aplicaciones externas: Habilita los flujos estándar de OAuth 2.0 para el inicio de sesión de usuario y el consentimiento de las aplicaciones fuera de Azure, mediante la identidad registrada de la aplicación en Entra ID.
Ejecución fuera de Azure (alternativa) App-Only o Delegado Identidad administrada Aporta ventajas de Azure: Al hospedar la aplicación en un servicio de proceso de Azure (como una máquina virtual o una aplicación contenedora), puede usar la seguridad mejorada y la capacidad de administración de identidades administradas, lo que evita la administración de credenciales aunque el origen pueda considerarse distinto de Azure.

Prerrequisitos

Aplicaciones que se ejecutan en Azure

En el caso de las aplicaciones que se ejecutan en Azure, se recomienda crear un tipo de identidad de Microsoft Entra denominada identidad administrada asignada por el usuario para acceder al recurso GeoCatalog. Las aplicaciones pueden usar las identidades administradas para obtener tokens de Microsoft Entra (consulte la sección Adquirir token de acceso para acceder a Microsoft Planetary Computer Pro sin tener que administrar credenciales. Para más información sobre identidades administradas y qué tipo elegir, consulte ¿Qué son las identidades administradas para los recursos de Azure? Para crear identidades administradas asignadas por el usuario para la aplicación que se ejecuta en Azure, siga Uso de identidades administradas para App Service y Azure Functions.

Aplicaciones que no se ejecutan en Azure

En el caso de las aplicaciones que no se ejecutan en Azure, como el entorno local o hospedado en otros proveedores de nube, se recomienda registrar la aplicación en el Centro de administración de Microsoft Entra, incluido un URI de redirección para recibir tokens de seguridad, para establecer una relación de confianza entre la aplicación y la plataforma de identidad de Microsoft. Registrar la aplicación en Microsoft Entra crea automáticamente un Principal de Servicio para la aplicación, al cual se pueden asignar roles de Control de Acceso Basado en Roles (RBAC) más adelante. Si su aplicación tiene una opción para configurar la autenticación de Microsoft Entra ID, puede usar el "ID de aplicación (cliente)" y el "ID de directorio (tenant)" de la aplicación registrada para hacerlo.

Si no puede registrar la aplicación en Microsoft Entra como se recomienda anteriormente, tiene otra opción de ejecutar la aplicación en una máquina virtual de Azure o en una aplicación contenedora. Puede crear una identidad administrada asignada por el usuario y asignarla a la máquina virtual (VM) o a la aplicación contenedora tal como se describe aquí: Configuración de identidades administradas en máquinas virtuales (VM) de Azure e identidades administradas en Azure Container Apps. La aplicación podría iniciar sesión con la identidad administrada para acceder al recurso GeoCatalog. Por ejemplo, para que la aplicación se ejecute dentro de una máquina virtual mediante una identidad administrada asignada por el usuario, puede usar:

!az login  --identity --username <client_id|object_id|resource_id> 

Puede encontrar el identificador de cliente, el identificador de objeto o el identificador de recurso de la identidad administrada desde Azure Portal. Como alternativa a la CLI, el código de Python de ejemplo se encuentra en la sección Adquisición del token de acceso para acceder a Microsoft Planetary Computer Pro.

azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)

Después de crear una identidad administrada asignada por el usuario o una entidad de servicio para la aplicación como se ha descrito anteriormente, debe decidir el tipo de escenario de acceso a la aplicación: acceso de solo aplicación, que actúa solo como identidad propia de la aplicación o acceso delegado, actuando en nombre de un usuario que ha iniciado sesión.

Acceso solo a aplicación

En este escenario de acceso, la aplicación actúa por sí sola sin que ningún usuario haya iniciado sesión como comportamiento predeterminado. Puede continuar con la sección Configuración de RBAC de Microsoft Planetary Computer Pro para aplicaciones para asignar los roles adecuados a la aplicación.

Acceso delegado

En este escenario de acceso, un usuario inició sesión en una aplicación cliente. La aplicación cliente accede al recurso en nombre del usuario. Debe asegurarse de que a los usuarios de la aplicación se les asignan roles de RBAC adecuados, tal y como se describe en la sección de Creación y administración de usuarios. También debe configurar los permisos de API de la aplicación con permisos delegados siguiendo estos pasos:

  1. Iniciar sesión en el Centro de administración de Microsoft Entra
  2. Vaya a Identidad>aplicaciones>Registros de apps, y luego seleccione su aplicación cliente.
  3. En Administrar, seleccione Permisos de API.
  4. Seleccione Agregar un permiso.
  5. Seleccione la pestaña API que usa mi organización .
  6. Escriba Azure Orbital Planetary Computer en el campo de búsqueda.
  7. Seleccione la entrada coincidente (el identificador de la aplicación debe ser 6388acc4-795e-43a9-a320-33075c1eb83b). Aparece como Azure Orbital Microsoft Planetary Computer Pro.
  8. Seleccione en el cuadro Permisos delegados . Active la casilla situada junto a user_impersonation.
  9. Seleccione Agregar permisos.
  10. Seleccione el vínculo "Conceder consentimiento del administrador" (suponiendo que la intención es conceder consentimiento del administrador en el inquilino para este permiso).

El patrón de autenticación delegada también se usa al conectarse desde QGIS.

Configuración de RBAC de Microsoft Planetary Computer Pro para aplicaciones

Una vez creada una identidad administrada para una aplicación que se ejecuta en Azure o una entidad de servicio para una aplicación que no se ejecuta en Azure, pero registrada en Microsoft Entra, debe conceder permisos adecuados a las identidades para acceder al recurso GeoCatalog mediante la configuración de RBAC.

A continuación se muestra un ejemplo paso a paso en el que se muestra cómo configurar Role-Based Access Control (RBAC) para asignar el rol "Administrador geocatalog" a la identidad administrada asignada por el usuario de una aplicación. Puede seguir estos mismos pasos en Azure Portal para configurar RBAC para la entidad de servicio de una aplicación.

  1. En Azure Portal, vaya a la pestaña IAM del recurso Microsoft Planetary Computer Pro de la izquierda.

    Captura de pantalla de la hoja IAM en Azure Portal para configurar RBAC.

  2. Seleccione Agregar asignación de roles y, a continuación, seleccione Administrador de GeoCatalog en "Roles de función de trabajo".

    Captura de pantalla de la selección de asignación de roles en Azure Portal.

  3. Seleccione el botón Siguiente y, a continuación, seleccione el botón de radio de Identidad administrada.

    Captura de pantalla de la selección de identidad administrada en Azure Portal.

  4. Seleccione Seleccionar miembros y seleccione la suscripción y la identidad administrada asignada por el usuario en el panel Seleccionar identidades administradas en el lado derecho.

    Captura de pantalla del panel miembros seleccionados en Azure Portal.

  5. Seleccione Siguiente para comprobar la información y finalizar la revisión y asignar.

Adquirir el token de acceso para acceder a Microsoft Planetary Computer Pro

Después de configurar RBAC para conceder a la aplicación los permisos adecuados, la aplicación debe adquirir un token de acceso para autenticar las solicitudes. Código de ejemplo de Python siguiente:

import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"} 

Nota:

Si su aplicación tiene varias identidades administradas asignadas, debe pasar explícitamente la correcta: azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>). Como alternativa, puede configurar las variables de entorno de su aplicación en el portal de Azure para agregar "AZURE_CLIENT_ID" con el identificador de cliente de identidad administrada adecuado.

Nota:

Puede agregar .default o user_impersonation como ámbito en credential.get_token() en función del comportamiento esperado de autenticación de usuario.

Nota:

Si la aplicación es una aplicación web, siempre que realice un cambio en el código o la configuración de la aplicación, asegúrese de cerrar y volver a abrir el explorador web para evitar que se usen credenciales almacenadas en caché.

Consulte Tokens de acceso en la Plataforma de identidad de Microsoft para obtener más información sobre los tokens de acceso. Al adquirir tokens de acceso mediante una llamada a DefaultAzureCredentials(), la instancia de credencial almacena en caché los tokens adquiridos. La duración del token y la actualización se controlan automáticamente. Puede pasar la instancia DefaultAzureCredential e invocar GetToken() o GetTokenAsync() justo antes de necesitar un token, de modo que siempre obtenga un token que no haya expirado. Si necesita mantener una sesión abierta larga, puede controlar la expiración del token en un controlador de errores para detectar la excepción y adquirir un nuevo token.

Si no puede usar DefaultAzureCredentials() y, en su lugar, usar otros métodos como AzureCliCredential() para adquirir tokens de acceso, debe administrar la duración y actualización del token. Consulte Vigencia de tokens configurable en la Plataforma de identidad de Microsoft y Actualización de tokens en la Plataforma de identidad de Microsoft para más información.

Pasos siguientes