Autenticación y autorización para Azure Health Data Services

Autenticación

Azure Health Data Services es una colección de servicios administrados protegidos mediante Microsoft Entra ID, un proveedor de identidades global que admite OAuth 2.0.

Para que Azure Health Data Services acceda a recursos de Azure, como cuentas de almacenamiento y centros de eventos, debe habilitar la identidad administrada por el sistema y conceder los permisos adecuados a la identidad administrada. Para obtener más información, consulte Identidades administradas de Azure.

Las aplicaciones cliente se registran en Microsoft Entra ID y se pueden usar para acceder a Azure Health Data Services. Los controles de acceso a datos de usuario se realizan en las aplicaciones o servicios que implementan lógica de negocios.

Roles de la aplicación

Los roles de aplicación deben asignarse a los usuarios autenticados y las aplicaciones cliente de Azure Health Data Services.

El servicio FHIR® de Azure Health Data Services proporciona estos roles:

• Lector de datos de FHIR: leer y buscar datos de FHIR.
• Escritor de datos de FHIR: leer, escribir y eliminar temporalmente datos de FHIR.
• Exportador de datos de FHIR: leer y exportar datos (operador $export).
• Importador de datos de FHIR: leer e importar datos (operador $import).
• Colaborador de datos de FHIR: realice todas las operaciones del plano de datos.
• Convertidor de datos de FHIR: use el convertidor para realizar la conversión de datos.
• Usuario FHIR SMART: permite al usuario leer y escribir datos de FHIR según las especificaciones de SMART IG V1.0.0.

El servicio DICOM® en Azure Health Data Services proporciona los siguientes roles:

• Propietario de datos de DICOM: leer, escribir y eliminar datos de DICOM.
• Lectura de datos de DICOM: leer datos de DICOM.

El servicio de tecnologías médicas no requiere roles de aplicación, pero se basa en el receptor de datos de Azure Event Hubs para recuperar los datos almacenados en el centro de eventos de la suscripción de la organización.

Authorization

Una vez concedidos los roles de aplicación, los usuarios autenticados y las aplicaciones cliente pueden acceder a Azure Health Data Services mediante la obtención de un token de acceso válido emitido por Microsoft Entra ID y realizar las operaciones específicas definidas por los roles de aplicación.

• Para el servicio FHIR, el token de acceso es específico del servicio o recurso.
• Para el servicio DICOM, el token de acceso se concede al recurso dicom.healthcareapis.azure.com, no a un servicio específico.
• En el caso del servicio de tecnologías médicas, el token de acceso no es necesario porque no está expuesto a los usuarios ni a las aplicaciones cliente.

Pasos para la autorización

Hay dos maneras comunes de obtener un token de acceso, que se describen en detalle en la documentación de Microsoft Entra: el flujo de código de autorización y el flujo de credenciales de cliente.

Aquí se muestra cómo se obtiene un token de acceso para Azure Health Data Services mediante el flujo de código de autorización:

1. El cliente envía una solicitud al punto de conexión de autorización de Microsoft Entra. Microsoft Entra ID redirige al cliente a una página de inicio de sesión donde el usuario se autentica mediante las credenciales apropiadas (por ejemplo, el nombre de usuario y la contraseña o la autenticación en dos fases). Después de que la autenticación se haya realizado correctamente, se devuelve un código de autorización al cliente. Microsoft Entra solo permite que se devuelva este código de autorización a una dirección URL de respuesta registrada configurada en el registro de la aplicación cliente.

2. La aplicación cliente intercambia el código de autorización para un token de acceso en el punto de conexión del token de Microsoft Entra. Cuando la aplicación cliente solicita un token, es posible que la aplicación tenga que proporcionar un secreto de cliente (que puede agregar durante el registro de la aplicación).

3. El cliente realiza una solicitud a Azure Health Data Services, por ejemplo, una solicitud GET para buscar a todos los pacientes en el servicio FHIR. La solicitud incluye el token de acceso en un encabezado de solicitud HTTP, por ejemplo, Authorization: Bearer xxx.

4. Azure Health Data Services valida que el token contenga las notificaciones adecuadas (propiedades del token). Si es válido, completa la solicitud y devuelve datos al cliente.

En el flujo de credenciales de cliente, los permisos se conceden directamente en la propia aplicación. Cuando la aplicación presenta un token a un recurso, este exige que la propia aplicación tenga autorización para realizar una acción, ya que no hay ningún usuario implicado en la autenticación. Por lo tanto, es diferente del flujo de código de autorización de estas maneras:

• El usuario o el cliente no necesitan iniciar sesión de manera interactiva.
• El código de autorización no es necesario.
• El token de acceso se obtiene directamente a través de permisos de aplicación.

Access token

El token de acceso es una colección de propiedades (notificaciones) codificada en Base64 y firmada que proporcionan información sobre la identidad del cliente, los roles y los privilegios que se conceden al usuario o al cliente.

Azure Health Data Services normalmente espera un JSON Web Token. Consta de tres partes:

• Encabezado
• Carga (las notificaciones)
• Firma, como se muestra en la imagen. Para obtener más información, consulte Tokens de acceso de Azure.

Use herramientas en línea como https://jwt.ms para ver el contenido del token. Por ejemplo, puede ver los detalles de las notificaciones.

Tipo de notificación	Valor	Notas
aud	https://xxx.fhir.azurehealthcareapis.com	Identifica al destinatario previsto del token. En los id_tokens, la audiencia es el identificador de aplicación de la aplicación, asignado a la aplicación en Azure Portal. La API debe validar este valor y rechazar el token si el valor no coincide.
iss	https://sts.windows.net/{tenantid}/	Identifica el servicio de token de seguridad (STS) que construye y devuelve el token, así como el inquilino de Microsoft Entra en el que se autenticó al usuario. Si el token fue emitido por el punto de conexión de la versión 2.0, el identificador URI finaliza con /v2.0. El GUID que indica que el usuario es un usuario consumidor desde una cuenta de Microsoft es 9188040d-6c67-4c5b-b112-36a304b66dad. La aplicación debe usar la parte del GUID de la notificación para restringir el conjunto de inquilinos que pueden iniciar sesión en la aplicación, si procede.
iat	(marca de tiempo)	La notificación "iat" (emitido a las) indica cuándo se produjo la autenticación de este token.
nbf	(marca de tiempo)	La notificación "nbf" (no antes de) identifica la hora antes de la cual no debe ser aceptado el token JWT para su procesamiento.
exp	(marca de tiempo)	La notificación "exp" (fecha de expiración) identifica la hora de expiración en la que o después de la que el token JWT no debe ser aceptado para su procesamiento. Un recurso podría rechazar el token antes de este tiempo, por ejemplo, si se requiere un cambio en la autenticación o se detecta una revocación de tokens.
aio	E2ZgYxxx	Una notificación interna usada por Microsoft Entra ID para registrar los datos para la reutilización de tokens. Se debe omitir.
appid	e97e1b8c-xxx	El identificador de aplicación del cliente mediante el token. La aplicación puede actuar por sí misma o en nombre de un usuario. Normalmente, el id. de aplicación representa un objeto de aplicación, pero también puede representar un objeto de entidad de servicio en Microsoft Entra ID.
appidacr	1	Indica cómo se autenticó el cliente. Para un cliente público, el valor es 0. Si se usan el id. de cliente y el secreto de cliente, el valor es 1. Si se usa un certificado de cliente para la autenticación, el valor es 2.
idp	https://sts.windows.net/{tenantid}/	Registra el proveedor de identidades que autenticó al firmante del token. Este valor es idéntico al valor de la notificación del emisor, a menos que la cuenta de usuario no esté en el mismo inquilino que el emisor: los invitados, por ejemplo. Si la notificación no está presente, significa que el valor de iss se puede usar en su lugar. Para las cuentas personales que se usan en un contexto de la organización (por ejemplo, una cuenta personal invitada a un inquilino de Microsoft Entra), la notificación idp puede ser “live.com” o un identificador URI de STS que contenga al inquilino de la cuenta Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid	Por ejemplo, tenantid	El identificador inmutable de un objeto en el sistema de identidades Microsoft, en este caso, una cuenta de usuario. Este identificador identifica de manera única el usuario entre aplicaciones: dos aplicaciones diferentes que inician sesión con el mismo usuario reciben el mismo valor en la notificación oid. Microsoft Graph devuelve este id. como la propiedad de id. de una cuenta de usuario determinada. Dado que oid permite que varias aplicaciones pongan en correlación a los usuarios, se requiere el ámbito de perfil para recibir esta notificación. Nota: Si un usuario existe en varios inquilinos, el usuario contiene un identificador de objeto distinto en cada inquilino: se consideran cuentas diferentes, incluso si el usuario inicia sesión en todas las cuentas con las mismas credenciales.
rh	0.ARoxxx	Una notificación interna que Azure usa para volver a validar los tokens. Se debe omitir.
sub	Por ejemplo, tenantid	La entidad de seguridad sobre la que el token declara información como, por ejemplo, el usuario de una aplicación. Este valor es inmutable y no se puede reasignar ni volver a usar. El firmante es un identificador en pares: es único para un identificador de aplicación determinado. Por lo tanto, si un usuario inicia sesión en dos aplicaciones diferentes con dos identificadores de cliente diferente, esas aplicaciones reciben dos valores diferentes para la notificación del firmante. Es posible que no desee este resultado en función de sus requisitos de arquitectura y privacidad.
tid	Por ejemplo, tenantid	GUID que representa el inquilino de Microsoft Entra del que procede el usuario. En el caso de las cuentas profesionales y educativas, el GUID es el identificador del inquilino inmutable de la organización a la que pertenece el usuario. Para las cuentas personales, el valor es 9188040d-6c67-4c5b-b112-36a304b66dad. El ámbito de perfil es necesario para recibir esta notificación.
uti	bY5glsxxx	Una notificación interna que Azure usa para volver a validar los tokens. Se debe omitir.
ver	1	Indica la versión del token.

El token de acceso es válido durante una hora de manera predeterminada. Puede obtener un nuevo token o renovarlo mediante el token de actualización antes de que expire.

Para obtener un token de acceso, puede usar herramientas como Postman, la extensión de cliente de REST en Visual Studio Code, PowerShell, la CLI, curl y las bibliotecas de autenticación de Microsoft Entra.

Cifrado

Cuando crea un nuevo servicio de Azure Health Data Services, de manera predeterminada los datos se cifran mediante claves administradas por Microsoft.

• El servicio FHIR proporciona cifrado de datos en reposo cuando los datos se conservan en el almacén de datos.
• El servicio DICOM proporciona cifrado de los datos en reposo cuando los datos de creación de imágenes, incluidos los metadatos incrustados, se conservan en el almacén de datos. Cuando los metadatos se extraen y se conservan en el servicio FHIR, se cifran automáticamente.
• El servicio de tecnologías médicas, después de la asignación de datos y la normalización, conserva los mensajes del dispositivo en el servicio FHIR, que se cifran automáticamente. En los casos en los que los mensajes del dispositivo se envían a Azure Event Hubs, que usa Azure Storage para almacenar los datos, los datos se cifran automáticamente con Azure Storage Service Encryption (Azure SSE).

Pasos siguientes

Implementación del área de trabajo de Azure Health Data Services mediante Azure Portal

Uso de Azure Active Directory B2C para conceder acceso al servicio FHIR

Nota:

FHIR® es una marca registrada de HL7 y se usa con su permiso.

DICOM® es la marca registrada de la Asociación Nacional de Fabricantes Eléctricos para sus publicaciones de normas relacionadas con las comunicaciones digitales de información médica.