Artículos y preguntas sobre la Autenticación OAuth2.
Buenas a todos,
en capítulos anteriores, vimos como "Proteger los datos: Se un mejor cerrajero", en el que explicábamos como proteger nuestros recursos aplicando un control extra al acceso mediante OAUTH2 que nos ofrece Intersystems. Y como no hay 2 sin 3, aquí tenemos un tercer articulo, en el cual vamos a explicar como "avisar a la policía" de que alguien malicioso está intentando acceder a nuestros datos.
¡Hola desarrolladores!
El Cuarto Concurso de Artículos Técnicos ha terminado. ¡Gracias a todos los participantes!
🤩 Habéis aportado 10 ARTÍCULOS INCREÍBLES, y ya podemos anunciar los ganadores.
Un fuerte aplauso para estos desarrolladores y sus artículos:
🏆 Nominación de los expertos - los ganadores han sido elegidos por un jurado especialmente formado para el concurso:
🥇 1er puesto: Carlos Castro con ¡POLICIA POLICIA! ¡¡Hay un intruso!! (Notificaciones Telegram y manejo URLs OAUTH2)
🥈 2º puesto: Miguelio con Persistencia de sesión Oauth con token OpenID en cookie
Tenemos un servidor OAuth configurado como proveedor de identidades, y tenemos una aplicación externa (de otro proveedor) que se conecta correctamente con el OAuth.
Por necesidades del proyecto, lo que queremos hacer es lo siguiente:
¿Conoces a Google? Seguro que si 😄 a menudo hacemos login en webs con nuestra cuenta de Gmail por la comodidad de simplemente hacer click! sin tener que escribir email ni contraseña, esto es posible porque nuestro navegador guarda un token de acceso que nos identifica y, en este caso Google, comparte un acceso para poder consultar información de nosotros como el correo electrónico.
🔐 Existen unas pautas o proceso para hacer esta identificación de forma segura, lo que se conoce como Oauth.
InterSystems IRIS 2025.2.0 introduce varias funcionalidades para mejorar la experiencia de configuración de OAuth2.
- OAuth2 es ahora un tipo de autenticación nativo y puede activarse fácilmente para vuestros servicios y aplicaciones web. Anteriormente, OAuth2 era un tipo de autenticación delegada.
- Ahora podéis crear servidores de recursos con la nueva clase OAuth2.ResourceServer, lo que simplifica considerablemente la configuración. Antes, los servidores de recursos eran instancias de OAuth2.Client.
Finalizamos esta serie de artículos de SMART On FHIR con Auth0 e InterSystems IRIS FHIR Repository revisando nuestra aplicación desarrollada en Angular 16.
Recordemos como es la arquitectura definida para nuestra solución:
Nuestra aplicación de front-end corresponde con la segunda columna y como véis será la encargada de dos cosas:
En vuestra Producción de Interoperabilidad, siempre podíais tener una Business Operation (BO) que fuera un cliente HTTP y que utilizara OAuth 2.0 para la autenticación. Sin embargo, teníais que personalizar la BO para esta metodología de autenticación. Desde la versión 2024.3, que se lanzó recientemente, hay una nueva capacidad que proporciona nuevos ajustes para gestionar esto de forma más sencilla.
Basado en una gran muestra y el taller construido por @Luis Angel Pérez Ramos (ver artículos relacionados y relacionados con Open Exchange app), que incluía un contenedor local de InterSystems IRIS for Health (y la configuración deseada), esta muestra presentada aquí, adaptó el taller para usar el Servidor FHIR en la Nube de InterSystems, y su configuración relacionada.
Buenas a todos,
en capítulos anteriores, vimos como "Como controlar el acceso a tus recursos con OAuth2". En este primer artículo explicábamos como preparar un acceso seguro a nuestros recursos utilizando la potente herramienta que nos ofrece Intersytems del servidor de Autenticación. Al finalizar el mismo, comentábamos que si quisiéramos podríamos aplicar un control extra a este acceso y esto nos lleva a este artículo, por lo que seguiremos el siguiente índice:
1.- Introducción
1.1..- De donde venimos
2.- Problema
2.1.- ¿Cómo funciona la llave (Token)?
He estado desarrollando una aplicación web que utiliza IRIS como back-end. Trabajé en ella con acceso no autenticado. Estoy llegando al punto en el que me gustaría implementarla para los usuarios, pero primero necesito añadir la autenticación. En vez de utilizar la contraseña para la autenticación predeterminada de IRIS (con contraseña), me gustaría que los usuarios iniciaran sesión con el Inicio de Sesión Único (SSO) de mi organización, o con algún otro proveedor de identidad popular como Google o GitHub. He leído que OpenID Connect es un estándar de autenticación común, y que es admitido por IRIS. ¿Cuál es la forma más sencilla de ponerlo en marcha?
La documentación muestra una opción bastante sencilla para utilizar una aplicación CSP como cliente de OpenID Connect.
Los pasos para ello son los siguientes:
Configurar el servidor OAuth 2.0 y el cliente en IRIS. Consultad la sección "Configuración de Caché" del estupendo artículo de Daniel Kutac para obtener más información.
Copie la rutina OAUTH2.ZAUTHENTICATE del repositorio de ejemplos en GitHub en el Namespace %SYS y renombrarlo como ZAUTHENTICATE.
Habilitar la autenticación delegada en todo el sistema.
Crear una página de inicio de sesión personalizada que se extienda desde %OAuth2.Login, y anule el método DefineParameters para especificar el nombre de la aplicación OAuth 2.0 y los ámbitos:
Class MyOAuth2.Login Extends %OAuth2.Login
{
ClassMethod DefineParameters(Output application As %String, Output scope As %String, Output responseMode As %String)
{
Set application="my application name"
Set scope="openid profile email"
Set responseMode=..#RESPONSEMODE
Quit
}
}Habilitar la aplicación web para la autenticación delegada y establecer la página de inicio de sesión personalizada en MyOAuth2.Login.cls.
Un truco final: Para que la página de inicio de sesión personalizada funcione, el usuario CSPSystem en IRIS necesita que se le conceda específicamente acceso de LECTURA (READ) a la base de datos en la que vive MyOAuth2.Login.cls.
En ese momento, el inicio de sesión debería "simplemente funcionar": visitar una página CSP en esa aplicación web redirigirá a la página de inicio de sesión en el proveedor de identidad. Después de iniciar sesión, el usuario tendrá una sesión CSP autenticada. Su $username será igual a su identificador de sujeto de SSO/Google/GitHub/donde sea, así que puedo utilizar la autorización incorporada de IRIS para determinar a qué cosas dar acceso.
¿Qué ocurre si la aplicación web utiliza un controlador REST? El proceso anterior no funciona. Si una aplicación web está habilitada para REST, no hay forma de definir una página de inicio de sesión personalizada. He descubierto que se necesitan algunos pasos más para solucionar este problema.
Crear una aplicación web independiente que no tenga REST habilitado. La ruta de esa aplicación debe comenzar con la ruta de la aplicación REST. Por ejemplo, si la aplicación REST se llama "/csp/api", podríamos llamar a esta nueva aplicación "/csp/api/login". Hay que habilitar la autenticación delegada y establecer la página de inicio de sesión personalizada en la página MyOAuth2.Login.cls.
Establecer la Ruta de la Cookie de Sesión en esta nueva aplicación como la misma que la de la aplicación REST: por ejemplo, "/csp/api". Esto permitirá que ambas aplicaciones compartan una sesión CSP.
Añadir una página CSP a esta nueva aplicación que actuará como "página de inicio". Un usuario deberá acceder primero a esta página para establecer su sesión. Este es un ejemplo que redirige a un endpoint en la API REST tras el inicio de sesión:
Class App.Home Extends %CSP.Page
{
ClassMethod OnPage() As %Status [ ServerOnly = 1 ]
{
&html<;>
return $$$OK
}
}Class API.REST Extends %CSP.REST
{
Parameter UseSession As BOOLEAN = 1;
XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
}
ClassMethod Test() As %Status
{
write { "username": ($username) }.%ToJSON()
return $$$OK
}
}En este punto, el inicio de sesión en la aplicación REST también "simplemente funcionará". El usuario visitará la página de inicio, será redirigido al inicio de sesión SSO y, finalmente, volverá a la aplicación REST, donde tendrá una sesión CSP autenticada. Hasta donde yo sé, ésta es la forma más sencilla de añadir OpenID Connect a una aplicación IRIS REST.
Otra opción es utilizar la muestra "REST.ZAUTHENTICATE" del repositorio de muestras de seguridad. Esto espera que el front-end adjunte un token de portador OAuth 2.0 a cada solicitud. Sin embargo, no hay una forma definida para que el front-end obtenga este token de acceso. Habrá que implementar ese flujo OAuth en JavaScript (o usar una librería como angular-oauth2-oidc.) También hay que asegurarse de que la aplicación JavaScript y el back-end de IRIS coinciden en todos los elementos de la configuración como el endpoint emisor del servidor de autorización, el id de cliente OAuth 2.0, etc. He descubierto que esto no es una tarea sencilla.
Tengo curiosidad por saber si alguien más utiliza OpenID Connect para autenticar una aplicación IRIS. ¿Existe una forma aún más sencilla? ¿O merece la pena utilizar el enfoque más complicado con tokens de portador? Podéis comentarlo más abajo.
En el pasado artículo presentamos la arquitectura de nuestro proyecto de SMART On FHIR, así que es hora de meternos en harina y empezar a configurar todos los elementos que vamos a necesitar.
Primeramente comenzaremos con Auth0.
Comenzaremos creando una cuenta de Auth0 con un correo válido, una vez dados de alta deberemos crear nuestra primera aplicación, y lo haremos desde el menú de la izquieda:
En nuestro ejemplo la aplicación será del tipo Single Page Web Application al tratarse una aplicación desarrollada en Angular 16. Seleccionamos dicha opción y pulsamos "Create".
Recientemente participé en un hands-on fantásticamente organizado por @Patrick Jamieson en el que se configuraba una aplicación de Angular junto con un servidor FHIR de IRIS siguiendo los protocolos definidos por SMART On FHIR y me resultó fráncamente interesante, por lo que me puse por mi cuenta a desarrollar mi propia aplicación de Angular y así aprovechar lo aprendido para publicarlo en la comunidad.
Veamos que nos dice Google de SMART On FHIR:
¡Hola Comunidad!
Hemos grabado el webinar que hicimos ayer y lo hemos subido al canal de YouTube de la Comunidad de Desarrolladores en español. Si os perdisteis el webinar o lo queréis volver a ver con más detalle, ya está disponible la grabación!
⏯ OAuth 2.0, OpenID Connect y LDAP: Cómo controlar el acceso a los recursos FHIR
¡Hola desarrolladores!
Os invitamos a un nuevo webinar en español: "OAuth 2.0, OpenID Connect y LDAP: Cómo controlar el acceso a los recursos FHIR", el jueves 1 de febrero, a las 4:00 PM (CET).
En un entorno clínico acelerado, en el que la toma rápida de decisiones es crucial, la falta de sistemas eficientes de almacenamiento y acceso a los documentos plantea varios obstáculos. Aunque existen soluciones de almacenamiento de documentos (por ejemplo, FHIR), el acceso y la búsqueda eficaz de datos específicos de pacientes dentro de esos documentos puede suponer todo un reto.
La IA ha hecho que la búsqueda de documentos sea extraordinariamente potente. Preguntar y responder sobre documentos nunca ha sido tan fácil con herramientas de código abierto como Chroma y Langchain para almacenar y utilizar incrustación de palabras (vector embeddings) para consultas a las APIs de IA generativa. Con un esfuerzo más dedicado, las organizaciones están indexando sus documentos existentes y construyendo versiones ajustadas de GPT con fines empresariales. La charla de Andrej Karpathy sobre el estado de GPT ofrece un excelente resumen general sobre este tema.
Este proyecto fue nuestro intento de reducir la fricción en todos los puntos de contacto en los que el personal médico tiene que interactuar con documentos. Desde la entrada y la gestión hasta el almacenamiento y la recuperación, hemos aprovechado IRIS FHIR y la IA para ayudarles a almacenar y encontrar la información que necesitan sin esfuerzo.
Hemos creado una aplicación web full-stack que permite a los médicos grabar notas de voz. A continuación, estas notas pueden transcribirse y resumirse mediante Open AI y almacenarse en servidores FHIR. Después, los documentos almacenados se indexan y están disponibles para la búsqueda semántica.
Clonad el repositorio del proyecto desde este enlace de GitHub: https://github.com/ikram-shah/iris-fhir-transcribe-summarize-export. Seguid las instrucciones proporcionadas para configurar el proyecto localmente en vuestros equipos. Y hacednos saber si algo no funciona como se esperaba.
Los avanzados modelos de lenguaje disponibles actualmente, combinados con el enorme volumen de datos disponibles, encierran un inmenso potencial para revolucionar la atención sanitaria, especialmente en lo relativo a los documentos.
Dejadnos vuestros comentarios a continuación. Publicaremos más artículos con los detalles técnicos de este proyecto.
En este artículo explicaré cómo, mediante programación, creé el usuario, concedí privilegios, habilité/deshabilité y autentifiqué/invalidé una aplicación web en mi aplicación Data_APP_Security (https://openexchange.intersystems.com/package/Data_APP_Security)
La autenticación verifica la identidad de cualquier usuario o entidad que intente conectarse a InterSystems IRIS®. Como se dice a menudo, la autentificación es la forma de demostrar que eres quien dices ser.
¡Hola Comunidad!
Seguramente habéis tod@s escuchado algo sobre Salesforce – la empresa y su software. En este articulo nos dedicaremos a la conectividad al software de CRM – Salesforce CRM. De una manera muy genérica, Salesforce CRM tiene la capacidad de administrar las interacciones con los clientes de una organización a través de varios métodos, como llamadas telefónicas, consultas por correo electrónico, comunidades, medios y redes sociales. Se dice que Salesforce maneja todas las relaciones con los clientes - centrándose en los procesos de ventas, soporte y marketing. Este servicio/software está disponible en la nube.
Qué bueno sería que pudiésemos conectarnos a Salesforce desde nuestro entorno InterSystems IRIS o cualquier otro producto de InterSystems.
Introducción
En este artículo, voy a contarles cómo logré realizar la integración en la plataforma Intersystems IRIS 2020 de una cuenta de correo Outlook Exchange con oAuth 2.0. Aunque esta tarea puede parecer sencilla, la realidad es que Intersystems IRIS 2020 no cuenta con los componentes necesarios para lograrlo. En mi caso, utilice código de la versión 2022 (puedes descargar la versión de evaluación) y lo adapté a la versión 2020. Si bien es factible actualizar entre versiones con el instalador IRIS 2022, esto toma semanas de pruebas antes de realizar el cambio en productivo, y la integración no podía esperar, es por esto que se optó por tomar componentes de IRIS 2022 y copiarlos/adaptarlos a la versión 2020.
Hola,
Estoy intentando obtener un Recurso FHIR usando OAuth 2.0. Obtengo access_token con éxito, pero cuando uso este token, me llega este tipo de error en Postman. Está mostrando un error 401 Unauthorized.
¿Me podrían proponer alguna solución?
Gracias
.png)
¿Te suenan OAuth2 / OpenID Connect pero no estás seguro de cómo se utilizan? ¿Has necesitado implementar alguna vez Single Sign On, servicios web seguros basados en tokens? ¿Has necesitado incorporar autenticación / autorización a tus aplicaciones web o servicios y no sabías por dónde empezar?
¿Que te parecería poder configurar paso a paso un servidor de autorización, un cliente y un servidor de recursos? Aquí tenéis un ejemplo donde se configuran instancias Intersystems IRIS para actuar como cada uno de esos roles de OAuth2.
Autenticación es el proceso de verificar que los usuarios son quienes dicen ser. Autorización es el proceso de otorgar a esos usuarios permisos para acceder a recursos.
OAuth2 es un framework de autorización. OpenID Connect es una extensión de OAuth2 para gestionar autenticación.
En OAuth2, existen diferentes roles:
Además, OAuth2 utiliza scopes o ámbitos como mecanismo para limitar acceso. Un cliente puede solicitar acceso a uno o varios scopes.
Y por último, OAuth2 soporta diferentes tipos de autorizaciones (grant types). Cada tipo de autorización puede tener un flujo diferente y ser más o menos indicada para un determinado tipo de escenario que nos interese montar.
## ¿Qué podrás probar en en el ejemplo?
Probarás dos escenarios. Uno con el tipo de autorización Authorization Code y otro con Client Credentials.
Tendrás 3 instancias de InterSystems IRIS que configurarás para actuar como cada de uno de los diferentes roles.
### Authorization code
Authorization code es un tipo de autorización indicada para escenarios de aplicaciones web / móviles.
En el ejemplo, configurarás lo necesario para tener un cliente web que accede a recursos protegidos utilizando un token de acceso.
Client credentials es otro tipo de autorización, se utiliza típicamente cuando un cliente quiere acceder a recursos directamente en su nombre (y no en el de un usuario).
En el ejemplo, lo utilizarás directamente desde Postman.
.png)
En este artículo, mostraré los conceptos básicos de la autenticación OAuth2 con la cuenta de GitHub con la ayuda de la demostración online
https://dappsecurity.demo.community.intersystems.com/csp/user/index.csp usando SuperUser | SYS
Así que... ¡empecemos!
¡Hola, desarrolladores!
En este artículo mostraré cómo configurar un repositorio FHIR + configuración del servidor de autorización/de recursos OAuth2 en IRIS for Health, como continuación del artículo anterior.
En la Parte 1, presentamos los preparativos preliminares, configuramos el servidor de autorización OAuth2 y obtuvimos el token de acceso.
En la Parte 2, mostraremos cómo crear un repositorio FHIR y cómo configurar un servidor de recursos/cliente OAuth2.
La configuración del repositorio FHIR y del servidor de recursos/cliente OAuth2 que haremos hoy se pueden utilizar por separado de la instancia IRIS del servidor de autorización OAuth2 que configuramos en la parte 1 anterior, o pueden tener una ubicación conjunta en la misma instancia. En este artículo, vamos a configurarlo en la misma instancia.
En este documento se describe como crear un repositorio FHIR: “Como instalar y configurar un servidor FHIR”.
En la siguiente pantalla, después de crearlo, haza clic en la URL del endpoint /csp/healthshare/fhirserver/fhir/r4 para abrir la pantalla de la configuración.
.png)
En la pantalla de configuración, introduce el nombre de configuración del cliente OAuth2 que vas a crear en el campo OAuth Client Name. Si ya has configurado un cliente OAuth2, haz coincidir su nombre.
.png)
En este ejemplo, utilizaremos la cadena "FHIRResource". Para cambiarla, haz clic en el botón “Edit” de la pantalla anterior y, a continuación, haz clic en “Update” para guardar los cambios.
.png)
A continuación, vamos a crear la configuración del cliente OAuth2.
Ve a System Administration → Security → OAuth2.0 en el Portal de Administración y selecciona “Client” en lugar de “Server”, a diferencia de la parte 1 anterior.
En la siguiente pantalla, haz clic en “Create Server Description” para crear la configuración para conectarse al servidor de autorización OAuth2. 
Para el endpoint del emisor, la página Server Description introduce el endpoint del servidor de autorización que se configuró en la Parte 1.
A continuación se muestra la pantalla de configuración del servidor de autorización OAuth2 que se configuró en la Parte 1.
Para la configuración SSL/TLS, introduce la configuración SSL/TLS “SSL4CLIENT” creada en los preparativos de la Parte 1.
Después de introducir los elementos, ¡ejecuta “Discover and Save” para obtener la información del servidor de autorización OAuth2!
Si el acceso funciona, se mostrará la información obtenida, como se muestra a continuación. Tenga en cuenta que puede ocurrir un error durante este proceso si el certificado SSL que especifica el hostname que preparaste previamente en los preparativos de la Parte 1 no se crea correctamente y no se reconoce.
Atención: Incluso si estás utilizando el archivo docker-container DL en la parte 1 de esta serie, puedes tener problemas para acceder al IRIS container -> Apache container al especificar el hostname. En este caso, puedes resolver el problema introduciendo el hostname y la dirección IP de tu equipo en el archivo docker-compose.yml como extra_hosts, como se muestra a continuación.
extra_hosts:
- <yourhostname>:<your ip address>
Una vez que hayas guardado la configuración, haga cliz en “Save” para volver a la siguiente página, y después selecciona “Client Configuration” para crear la configuración del repositorio FHIR.
Es un título complicado, pero el siguiente paso es agregar la configuración del cliente (la información sobre el repositorio FHIR específico, la aplicación CSP, etc. que quieres conectar al servidor de autorización OAuth2 como un cliente OAuth2) a la configuración del cliente OAuth2 que acabas de crear (con información sobre el servidor de autorización OAuth2 al que conectar).
En la siguiente pantalla, haz clic en “Create Client Configuration” para mostrar la siguiente pantalla y establecer los elementos necesarios.
Si primero seleccionas client type = Resource Server, la pantalla de entrada será la misma que la siguiente.
| Application Name | FHIRResource: pon el valor que pusiste para "OAuth Client Name" en la configuración del Repositorio FHIR. |
| Client Name | Es el nombre del cliente que se registrará en el servidor de autorización OAuth2. Puede ser el mismo que el nombre de la aplicación; sin embargo, hemos elegido un nombre diferente. |
| Description | Introduce una descripción para esta configuración. |
| Type of client | Selecciona “Resource Server”. |
| SSL/TLS configuration | Especifica la configuración SSL/TLS que preparaste previamente en los preparativos de la Parte 1. |
Después de completar el formulario, haz clic en el botón “Dynamic Registration and Save” para guardar y registrar el archivo en el servidor. Es un poco confuso, pero cuando el botón cambia de “Dynamic Registration and Save” a “Get Update Metadata and Save”, el registro ha salido bien.
Vamos a echar un vistazo a la información de la configuración del lado del servidor de autorización OAuth2 y comprobaremos si está registrado.
En la página Management Portal→System Administration→Security Management→OAuth2.0→Server, haz clic en “Client Description”, y verás que está registrado, como se muestra a continuación 
Confirma que el nombre es el que especificaste en el client name.
En la Parte 1, cuando probamos el acceso desde Postman, copiamos manualmente el ID del cliente y la clave privada que se muestra más abajo en la pantalla del descriptor del cliente. Sin embargo, esta vez, esta información se pasa al lado del cliente durante el proceso de registro dinámico.
Por último, ¡es el momento de acceder a él desde Postman!
En primer lugar, necesitamos obtener un token de acceso. El método básico es el mismo que utilizamos al final de la Parte 1, pero necesitamos agregar un parámetro de audiencia para indicar dónde se emitirá el token de acceso.
aud=https://[hostname]/csp/healthshare/fhirserver/fhir/r4
Para añadirlo específicamente en Postman, añadelo como un parámetro a la URL del endpoint del Código de Autorización de la siguiente forma: (Debido a las limitaciones de la pantalla de Postman, no puedes ver todos los parámetros, pero incluye todos los de arriba aud=https://[hostname]/csp/healthshare/fhirserver/fhir/r4 )
.png)
Atención: No es necesario cambiar el Client ID y el Client Secret que pusiste en Postman a los emitidos anteriormente en el registro dinámico del servidor de recursos. Utiliza el Client ID y la clave secreta (Secret key) emitida para Postman que añadiste en la parte 1.
Después de obtener el token de acceso, copia su contenido.
En Postman, si dejas TYPE of Authorization como OAuth2, se activará una función para enviar el token de acceso. Sin embargo, en el repositorio FHIR de IRIS for Health, también es necesario enviar la información del usuario y la contraseña de la Basic Auth.
Para ello, al acceder desde Postman, el TYPE of Authorization (lo cual es un poco molesto) debe ser Basic Auth, se debe introducir el nombre de usuario y la contraseña, y se debe enviar el token de acceso como un Parámetro en la solicitud REST para el repositorio FHIR.
De manera detallada: primero, introduce el nombre de usuario y la contraseña como se muestra en la siguiente pantalla. Esta información de usuario se comprobará para ver si coincide con la información de usuario en el sub token de acceso; por eso, debe ser el mismo usuario que la información de usuario que introdujiste cuando obtuviste el token de acceso.
.png)
En la pestaña Params, para access_token, escribe el valor del token de acceso que acabas de introducir para el parámetro.
.png)
Si acabas de crear el repositorio FHIR, no hay datos en el repositorio, ¡pero puedes solicitar datos de pacientes!
Para la URL de la solicitud (Request URL), escribe https://[hostname]/csp/healthshare/fhirserver/fhir/r4/Patient, y selecciona GET como el método HTTP (como se muestra en la figura anterior).
¡Haz clic en el botón “Send” para enviar la solicitud! Si obtienes el paquete FHIR como se muestra a continuación, ¡has accedido al repositorio FHIR por medio del token de acceso!
.png)
Para obtener más información sobre cómo registrar y buscar datos en el repositorio FHIR, consulta la documentación de IRIS for Health y los artículos de la comunidad.
Documentación del Repositorio de recursos para IRIS for Health 2020.3.
¿Cómo fue tu experiencia al acceder al repositorio FHIR?
La configuración descrita en esta serie es la más sencilla. En un proyecto FHIR real, el alcance de los datos que van a ser devueltos dependerá del alcance aprobado por el usuario, y esto deberá ser considerado e implementado.
Os seguiremos informando sobre FHIR.
¡Hola desarrolladores!
En este artículo, nos centraremos en OAuth2, un protocolo que se utiliza cada vez con más frecuencia en combinación con FHIR para realizar la autorización.
En esta primera parte, comenzaremos con el contenedor Docker para IRIS for Health y Apache, configuraremos la función del servidor de autorización OAuth2 en IRIS for Health, accederemos a él desde la herramienta de desarrollo Postman para REST y obtendremos un token de acceso. Además, en la Parte 2 y en las siguientes, añadiremos las funciones del repositorio FHIR a IRIS for Health, también agregaremos la configuración del servidor de recursos OAuth2, y explicaremos cómo ejecutar las solicitudes de FHIR utilizando los tokens de acceso desde Postman.
En la Comunidad de Desarrolladores ya se han publicado varios artículos excelentes donde se explican las funciones de OAuth2 en los productos de InterSystems; sin embargo, me gustaría explicar nuevamente cómo configurar la última versión. Cómo implementar la estructura de InterSystems IRIS Open Authorization (OAuth 2.0) - Parte 1
En este artículo, utilizaremos la última versión de InterSystems IRIS for Health 2020.3 (es una versión de prueba). Si quieres desarrollar un entorno basado en este artículo, asegúrate de utilizar esta versión o una posterior del kit. Algunas características no están incluidas en los productos anteriores a esta versión.
El primer paso es hacer unos preparativos preliminares. Son muchas las cosas que deben prepararse para crear un entorno seguro.
La versión de prueba de IRIS for Health 2020.3 solo está disponible en una versión para el contenedor Docker (InterSystems Docker Hub/IRIS for Health). Para efectuar la configuración de OAuth2, también deberás realizar la configuración del servidor web y de SSL. En este artículo, utilizaremos Apache. Al realizar la configuración de SSL en Apache, el certificado de configuración de SSL debe coincidir con el nombre del servidor. Ten en cuenta este punto.
El archivo docker-compose.yml/Dockerfile y otros archivos de muestra utilizados en esta configuración están disponibles en el repositorio de GitHub reservado para la Comunidad de Desarrolladores de InterSystems. En primer lugar, descomprime este archivo en tu entorno utilizando el siguiente comando. (También puedes hacerlo desde el archivo adjunto que se encuentra en este artículo). Este archivo docker-compose.yml/Dockerfile y otros archivos se crean tomando como referencia la aplicación iris-webgateway-example publicada en OpenExchange.
git clone https://github.com/Intersystems-jp/IRIS4H-OAuth2-handson.git
En este archivo docker-compose.yml, se configuran dos contenedores para iniciarse: el contenedor de IRIS for Health y el contenedor de Apache (httpd) se crearán por el comando docker build. El archivo docker-compose.yml, disponible en GitHub, hace referencia a la versión de prueba 2020.3.200.0 de la Community Edition de IRIS for Health. La Community Edition puede utilizarse para evaluar los productos de InterSystems.
iris:
image: store/intersystems/irishealth-community:2020.3.0.200.0
Si utilizas una versión diferente (la versión oficial o una más reciente), cambia esta parte de la especificación.
El contenedor Apache se creará con el contenido del Dockerfile, que requiere un kit WebGateway para conectarse a IRIS desde Apache. Para saber cómo conseguir el kit, contacta con el Centro de Soporte Internacional (WRC) de Intersystems. Para consultas sobre el SO del servidor, puedes ponerte en contacto con nosotros en esta dirección.
Modifica las siguientes partes del Dockerfile según el producto que hayas obtenido. Independientemente del SO del servidor (Windows/Ubuntu/CentOS), la plataforma será lnxubuntux64 porque el SO base del contenedor httpd es Debian.
ARG version=2020.3.0.200.0
ARG platform=lnxubuntux64
ADD WebGateway-${version}-${platform}.tar.gz /tmp/
En el siguiente paso, se prepara un certificado SSL. Cuando se accede a la autorización OAuth2, debe comprobarse si el certificado SSL establecido en el servidor web coincide con la URL a la que se tiene acceso. No es necesario utilizar un certificado oficial, es posible utilizar OpenSSL, etc. Introduce el nombre del servidor en el campo "Common Name" al crear el certificado.
Además, como el certificado que acabas de crear se cargará automáticamente durante el arranque, debes cambiar el archivo por uno que no requiera una contraseña. Consulta el siguiente comando.
$ openssl rsa -in cert.key.org -out cert.key
Coloca los archivos CRT y KEY que se crearon, en el mismo directorio con el Dockerfile, con los nombres de archivo server.crt / server.key respectivamente.
Además de utilizarlo con el servidor web Apache, necesitarás un certificado SSL para la configuración de OAuth2. Estos no requieren que introduzcas un nombre de servidor, etc., pero debes crear tres conjuntos (En las configuraciones posteriores, aparecen como auth.cer/auth.key, client.cer/client.key, resserver.cer/resserver.key).
¡Ya estás listo! Además de los cuatro archivos que descargaste, ahora tienes un kit de instalación Web Gateway y dos certificados SSL en tu directorio. Ten cuidado con los permisos de acceso y ejecución de cada archivo (por ejemplo, yo añadí el permiso de ejecución para webgateway-entrypoint.sh).
docker-compose build
docker-compose up -d
Una vez iniciado, utiliza el comando docker ps para verificar que los dos contenedores están en ejecución.
Apache Container name：<directoryname>_web
IRIS for Health container name：store/intersystems/irishealth-community:2020.3.0.200.0（or other name depend on kit)
Ahora, intenta acceder al portal de administración mediante alguna de estas tres formas. Si el tercer método funciona, ¡tu configuración SSL a través del servidor web Apache es un éxito!
http://[hostname]:52773/csp/sys/UtilHome.csp ：A esta URL se accede a través del servidor Apache privado en el contenedor IRIS. Este no pasa por el Apache que se configuró.
http://[hostname]/csp/sys/UtilHome.csp ：Esta URL accede al portal de administración a través del Apache que se configuró.
https://[hostname]/csp/sys/UtilHome.csp ：Esta URL accede al Portal de administración utilizando una conexión SSL a través del Apache que se configuró.
Ahora que IRIS for Health está listo y en funcionamiento, y tenemos acceso al Portal de administración, vamos a crear la configuración SSL para los últimos preparativos.
Ve a Management Portal -> System Administration -> Security -> SSL/TLS Configuration y crea tres configuraciones SSL utilizando los tres pares de certificado/llave que preparaste.
Puedes seleccionar el nombre que quieras, pero en este artículo utilizaremos SSL4AUTH/SSL4CLIENT/SSL4RESSERVER, siguiendo los artículos anteriores relacionados con OAuth2.
*Acerca de compartir directorios entre servidores y contenedores
En la siguiente especificación de volúmenes que se encuentra en el archivo docker-compose se muestra la ubicación actual del directorio host = /ISC en el contenedor. Utiliza este directorio cuando especifiques el archivo del certificado en la configuración anterior, etc.
volumes:
- .:/ISC
Este directorio no solo contendrá archivos, sino también archivos de la base de datos IRIS y archivos de la configuración. Consulta el documento “Persistencia de %SYS para almacenar datos de instancias persistentes” para obtener más información.
¡Ahora es el momento de entrar en los detalles del acceso a IRIS for Health utilizando OAuth2!
Primero, vamos a configurar el servidor de autorización OAuth2. Ve a Management Portal → System Administration → Security → OAuth 2.0 → Server.
Sigue estas instrucciones para ajustar la configuración.
| Configuración en la pestaña “General” | |
|---|---|
| Issuer endpoint: Host name | Escribe el nombre actual del servidor |
| Issuer endpoint: Prefix | Puedes escribir cualquier valor que quieras, pero aquí lo establecimos como “authserver”. |
| Supported grant types | En este artículo, solo utilizaremos “Authorization Code”, pero si quieres probar otros “Grant Types”, añade una marca de verificación. Además, añade una verificación a la “JWT authorization” |
| SSL/TLS configuration | Especifica la configuración SSL que acabas de añadir. |
En la pestaña “Scopes", haz clic en “Add Supported Scope” para añadirlos. Más adelante, la pantalla de inicio de sesión del Código de Autorización mostrará la “Descripción” que escribiste aquí.
No hagas cambios de la configuración predeterminada en la pestaña “Intervals". En la pestaña “JWT Settings”, seleccionaremos “RS512” como el algoritmo de firma.
En la última pestaña de “Customization”, cambia la especificación Generate Token Class a %OAuth2.Server.JWT.
Una vez que hayas introducido la información, haz clic en el botón “Save” para guardar la configuración.
Ahora que tienes la configuración necesaria para que IRIS for Health se ejecute como un servidor de autorización de OAuth2, ¡estás listo para probarlo! ¡Intentaremos acceder desde Postman y veremos si podemos obtener un token de acceso!
Sin embargo, antes de hacer eso, necesitamos configurar dos cosas más.
En primer lugar, añade la información de Postman para acceder como un cliente de OAuth2. El registro de clientes de OAuth2 se puede añadir por medio del registro dinámico u otros métodos.
Haz clic en “Client Description” en la página de configuración del servidor para continuar.
Haz clic en “Create Client Description” para añadir una entrada.
Sigue estas instrucciones para crear una suscripción de cliente.
| Configuración en la pestaña “General” | |
|---|---|
| Name | Escribe el nombre que quieras. En este caso, hemos elegido “postman”. |
| Client Type | Elige “Confidential” |
| Redirect URLs | Haz clic en el botón “Add URL” para añadir una URL de redirección para Postman. https://www.getpostman.com/oauth2/callback como la URL de redirección para Postman. |
| Supported grant types | Especifica el mismo “Authorization Code” (Código de autorización) configurado en la configuración del servidor de autorización de OAuth2. (Predeterminado) Añade una marca si quieres probar también otros tipos de permisos. Sin embargo, la configuración debe ser la misma que la del servidor de autorización. Además, marca la casilla “JWT authorization”. Especifícalo aquí |
| Authenticated Signing Algorithm | Marca la opción "Autorización JWT" en Supported grant Types para que se pueda seleccionar. Selecciona “RS512”. |
Una vez que hayas introducido la información, haz clic en el botón “Save” para guardar la descripción del cliente.
Haz clic en la pestaña “Client Credentials” para ver el client ID y la clave privada del cliente para esta entrada. Necesitarás este ID y la clave privada cuando realices las pruebas desde POSTMAN.
Es necesario agregar una configuración más antes de acceder desde POSTMAN. La pantalla de configuración del servidor de autorización OAuth2 ha determinado que el endpoint para esta configuración es https://<hostname>/authserver/oauth2. Para que el acceso a este endpoint sea administrado correctamente por IRIS, necesitamos añadir una aplicación web para esta ruta de URL.
Ve a System Administration→Security→Applications→Web Applications, y haz clic en “Create a new web application”.
Se proporciona una plantilla de aplicación web OAuth2, así que primero, selecciona “/oauth2” desde “Copy from”.
| Configuración de “Edit Web Application” | |
|---|---|
| Copy From | “/oauth2” : Siempre selecciona este primero desde el menú desplegable. |
| Name | /authserver/oauth2 |
| Enable | Marca el botón de la opción “REST”. |
Después de introducir cada valor, guárdalo.
Lo vamos a probar desde POSTMAN. Las pruebas también se pueden ejecutar desde otras herramientas o desde el propio programa. La explicación detallada de POSTMAN va más allá del alcance de este artículo, pero cabe señalar que la verificación del certificado SSL debe cambiar a OFF en la configuración de POSTMAN.
Después de crear una nueva solicitud en POSTMAN, selecciona “OAuth 2.0” en la pestaña TYPE of Authorization y haz clic en “Get New Access Token”.
.png)
En la siguiente pantalla, introduce los valores según lo siguiente.
| Configuración「GET NEW ACCESS TOKEN」 | |
|---|---|
| Token Name | Escriba el nombre que quieras. |
| Grant Type | Selecciona “Authorization Code”. |
| Callback URL | https://www.getpostman.com/oauth2/callback |
| Auth URL | "https://<hostname>/authserver/oauth2/authorize" Introduce el valor del endpoint +/"authorize". Al añadir "? ui_locales=ja", puedes mostrar la pantalla de inicio de sesión en japonés. |
| Auth Token URL | https:// |
| Client ID | Introduce el client ID que aparece en la pestaña de Client Credentials después de registrarte para la descripción del cliente. |
| Client Secret | Introduce la clave privada del cliente, que se muestra en la pestaña Client Credentials después de registrar la descripción del cliente. |
| Scope | Introduce el scope registrado en la configuración del servidor de autorización, por ejemplo, “scope1”. También puedes especificar varios scopes separados por espacios. |
| State | Introduce el parámetro State, que se utiliza para las medidas contra el CSRF. No se utiliza explícitamente, pero no se puede dejar en blanco, por lo que se introduce una cadena arbitraria. |
.png)
Después de introducir los parámetros y hacer clic en el botón “Request Token”, verás la pantalla de inicio de sesión:
Intenta iniciar sesión con la información del usuario (por ejemplo, _SYSTEM) con acceso al Portal de administración.
En la siguiente pantalla después del inicio de sesión, puedes decidir conceder permisos a esta aplicación. Después de hacer clic en “Allow”, si el token de acceso aparece en la siguiente pantalla, como se muestra a continuación, ¡la prueba de adquisición del token de acceso se realizó con éxito!
.png)
IRIS for Health puede llevar a cabo el procesamiento de autorización de OAuth2, así como el procesamiento de autenticación compatible con OpenID Connect. Consulta este documento para obtener más información.
En esta configuración, OpenID Connect está habilitado, ¡así que vamos a probar si también podemos obtener el token de ID de OpenID Connect!
Es fácil de implementar. En la pantalla GET NEW ACCESS TOKEN, añade “openid” al scope y realiza una solicitud.
.png)
OpenID Connect también se mostrará en la página de solicitud de autorización. Después de que hayas iniciado sesión y hayas dado tus permisos, asegúrate de obtener también un token de identificación (id_token) cuando veas la siguiente pantalla. (Es posible que necesites desplazarse hacia abajo por la pantalla.)
.png)
¿Pudiste obtener el token de acceso y el id_token?
Aunque hay algunos preparativos, como los certificados que requieren un poco de tiempo y esfuerzo, podríamos construir un servidor de autorización OAuth2 muy sencillo utilizando IRIS for Health.
En el siguiente artículo de esta serie, finalmente os mostraré cómo crear un repositorio FHIR y registrarlo como un servidor de recursos OAuth2. Y también cómo acceder con REST al repositorio FHIR por medio de un token de acceso OAuth2 desde POSTMAN.
Este artículo, y los dos siguientes de la serie, se conciben como una guía para los usuarios, los desarrolladores o para los administradores de sistemas que necesiten trabajar con la estructura de OAuth 2.0 (conocido también por simplicidad como OAUTH) en aplicaciones que estén basadas en los productos de InterSystems.