Domar protocolos de confianza: autenticación OAuth con InterSystems IRIS

¿Cómo permitir que las computadoras confíen entre sí en su ausencia, mientras mantienen la seguridad y la privacidad?



- Martini seco. En un gran vaso.
- Oui, señor. [Sí, señor (p.)]
"Solo un segundo, no todos". Tres dedos de Gordon, uno de vodka, medio dedo de Kina Lyklet. Batir bien en una coctelera y luego poner una rodaja grande de limón. ¿Te acuerdas?

Jan Fleming, Casino Royale, 1953

Parte 1. Historias de OAuth 2.0 y OpenID Connect

Universal y, al parecer, hoy en el siglo XXI, el conjunto favorito de protocolos de autenticación y delegación de acceso abierto de todos se llama OAuth + OIDC. Mejor para el uso masivo hasta ahora no se le ocurrió nada. Son especialmente populares entre los proveedores front-end porque caminan sobre los protocolos HTTP (S) y usan el contenedor JWT ( JSON Web Token ). OpenID Connect utiliza OAuth para su trabajo o, en otras palabras, OIDC es un contenedor para OAuth.

OpenID: un estándar abierto para la autenticación y la creación de sistemas de identificación digital no es nuevo para los desarrolladores. Este año, cumple 14 años. En la tercera versión actual, el nombre completo es OpenID Connect o más corto que OIDC. Es popular tanto en el desarrollo web y móvil, como en los sistemas corporativos.

Su socio, el Estándar de Delegación de Acceso Abierto de OAuth, cumple 12 años. Y 9 años desde que apareció el estándar RFC 5849 correspondiente. Confiaremos en la versión moderna del protocolo OAuth 2.0 y el RFC 6749 actual. Recuerde que OAuth 2.0 no es compatible con su predecesor OAuth 1.0.

OAuth: un protocolo abierto (esquema, transporte) para delegar el acceso, que permite proporcionar a terceros acceso limitado a los recursos protegidos del usuario sin la necesidad de transferir a ellos (terceros) el nombre de usuario y la contraseña de RFC 6749

oauth.net es el sitio web líder de OAuth alojado por Aaron Parecki

oauth.com - Tutorial de OAuth y entorno de prueba

Open ID Connect (OIDC) es un estándar abierto para sistemas de identificación descentralizados que permite al usuario crear una sola cuenta para identificación en una variedad de recursos de Internet no relacionados que utilizan servicios de terceros, utiliza mensajes OAuth y un contenedor JWT para una comunicación segura.

Estrictamente hablando, OAuth no es un protocolo, sino un conjunto de reglas (esquema) para separar y transferir operaciones de identificación de usuarios a un servidor de confianza separado al implementar la arquitectura de delimitación de control de acceso en sistemas de software.

Y, atención, ¡ OAuth no puede decir nada sobre un usuario específico ! Ni quién es, ni dónde está ahora, ni si trabaja en la computadora ahora o no. Pero luego permite interactuar con los sistemas sin intervención del usuario, utilizando tokens de acceso ya emitidos. Este es un punto importante.

Puede ser útil:

• OAuth combina perfectamente con el uso del lenguaje de descripción de acceso de atributos XACML
• OAuth también se basa en el acceso administrado por el usuario ( UMA )

El uso conjunto de OAuth + OIDC + UMA permite implementar sistemas de identificación segura y control de acceso (Identity and Access Management - IdM, IAM) en diferentes áreas temáticas, por ejemplo:

• utilizando el perfil HEART (Health Relationship Trust) de los datos personales de un paciente en medicina
• en las plataformas de identificación de clientes CIAM (Consumer Identity and Access Management) para empresas manufactureras y comerciales
• personalización de certificados digitales de dispositivos inteligentes en sistemas IoT (Internet of Things)

Una nueva forma de control de acceso para la economía API

Lo más importante, no almacene datos personales en el mismo lugar que el resto del sistema. Separar físicamente la autenticación y autorización. Y aún mejor: dele toda la identificación personalmente a la persona y nunca la lleve consigo. Confía en el propietario del dispositivo.

Apple dijo qué datos personales almacenan los rusos en Rusia. Este es el nombre, dirección, correo electrónico, número de teléfono. Pero las personas de Mensajes, fotos, etc., confían en la nube de iCloud (que no está en Rusia).

Parte 2. Juego corto "Confianza y autenticación"

Por lo tanto, decidimos que no era fabuloso almacenar los datos personales de nuestros queridos usuarios ni en nuestra aplicación, ni en un único almacenamiento junto con una base de datos operativa. Es decir, han elegido un administrador confiable que nos brindará este servicio. Y así, cuando aparece Su Majestad el Usuario, entonces proporcionamos el siguiente diálogo.

Actores:

• Usuario
• Solicitud de cliente
• Servicio de identidad
• Servidor de recursos

La acción tiene lugar en un navegador en la computadora del usuario. Todos los personajes han estado familiarizados el uno con el otro. El usuario tiene una cuenta personal en el servicio de identidad. La Aplicación del cliente tiene un contrato válido firmado con el Servicio de identificación y las interfaces mutuas. El servidor de recursos confía en el servicio de identidad en la cuestión de emitir claves de acceso a cualquier víctima a quien pueda identificar.

Usuario (P): (al iniciar una aplicación cliente basada en la web) Estimado cliente-aplicación, necesito "este recurso".
Aplicación de cliente (K): Estimado usuario, primero presente la clave de "este recurso". Sin una clave, el acceso a "este recurso" está cerrado.
P: No tengo esa clave.
K: Luego lo cambiaré temporalmente a un servicio de identificación con el que tenemos un acuerdo para emitir claves para el servidor de recursos. (redirige P. al servicio de identificación)
Servicio de identificación (I): Estimado usuario, dígame quién es usted y qué claves necesita.
P: Yo, usuario de Ytsuken User, la contraseña es tal y tal, quiero obtener acceso a "este recurso".
Y: gracias, camarada Jtsuken. La autenticación se realizó correctamente y se verificó su identificación. Aquí está la clave de "este recurso" (P. vuelve a dirigir a K.)
P: Cliente, te traje la clave del "recurso" que necesito.
K: Gracias usuario. La clave es correcta. Aquí está el "recurso" que solicitó.

El telón Se reproduce la sinfonía de apertura de Richard Strauss de la película "Space Odyssey of 2001"

Parte 3. Servicio de autorización real

Ahora vamos al grano. Tenemos tres tareas en la agenda: nombrar a los personajes, preparar el escenario y jugar la obra. Y todo se decide a la vez en la plataforma InterSystems IRIS. Pero esto no es necesario, puede armar un diseño desde diferentes plataformas a su discreción. Por ejemplo, en esta combinación: servidor OAuth Keycloak + cliente OAuth y recurso OAuth en IRIS. En otras palabras:

1. Configure e inicie el servidor OAuth con el registro de nuestro cliente de demostración.
2. Configure un cliente OAuth de demostración conectándolo al servidor OAuth y a los recursos web.
3. Desarrolle aplicaciones cliente que puedan usar OAuth. Puede usar Java, Python, C #, NodeJS. El siguiente es un código de aplicación de muestra en ObjectScript.

El sitio web de la comunidad de desarrolladores cuenta con instrucciones detalladas de Daniel Kutak en tres partes con ejemplos de uso de OAuth en IRIS para diferentes aplicaciones basadas en CSP ( parte 1 , parte 2 , parte 3 ).

Hay muchas configuraciones en OAuth. Por lo tanto, escríbete listas de verificación: esta es la aplicación más correcta para ellos. Ejemplos y espacios en blanco a continuación.

¿Dónde obtener InterSystems IRIS listo para una muestra? Hay al menos dos opciones disponibles para todos:

Obtenga un servidor IRIS en la nube preconfigurado listo para usar en la plataforma de capacitación de InterSystems Learning Services en la sección InterSystems Learning Labs.

Instale un contenedor acoplado listo para usar . Lea más en el artículo: una instrucción paso a paso para principiantes en el lanzamiento de desarrolladores de IRIS con Docker o, si prefieren un video, una instrucción de screencast de Desarrollo de soluciones con InterSystems IRIS con Docker y VSCode

1-1 Configuración del servidor OAuth

Entramos en el portal de gestión de IRIS y seleccionamos la sección:

Administración del sistema >> Seguridad >> OAuth 2.0 >> Servidor

A continuación, en cada párrafo, habrá un nombre para la línea de configuración y, a través de los dos puntos, un ejemplo o explicación, si es necesario.



Pestaña Configuración general:
Descripción: opcional, por ejemplo, "Servidor de autorización"
El punto final del generador (en adelante CTG) es el nombre de host: nombre DNS de su servidor
Tipos de permisos admitidos (seleccione al menos uno):
Código de autorización
Implícito
Credenciales: recurso, propietario, contraseña
Credenciales del cliente
Configuración SSL / TLS: oauthserver

Pestaña de permisos:
agregar volúmenes compatibles: por ejemplo, alcance1 y alcance2

Pestaña Intervalos:
Intervalo de clave de acceso: 3600
Intervalo de código de autorización: 60
Actualizar intervalo de clave: 86400
Intervalo de interrupción de sesión: 86400
Período de validez de la clave del cliente: 0

Pestaña de configuración de JWT:
Algoritmo de entrada: RS512
Algoritmo de gestión de claves: RSA-OAEP
Algoritmo de cifrado de contenido: A256CBC-HS512

Pestaña de personalización:
Identificar clase:% OAuth2.Server.Authenticate
Verificar clase de usuario:% OAuth2.Server.Validate
Clase de servicio de sesión: OAuth2.Server.Session
Generar clase de clave:% OAuth2.Server.JWT
Espacio de nombres de personalización:% SYS
Roles de personalización (seleccione al menos uno):% DB_IRISSYS y% Manager

Guardar.

1-2 Registre el cliente en el servidor OAuth

Botón Descripción del cliente >> Botón Crear descripción del cliente:

Pestaña Configuración general:
Nombre: CLIENTE
Descripción: arbitraria
Tipo de cliente: confidencial
URL de redireccionamiento: la dirección del punto de retorno en nuestra aplicación después de la autenticación
Tipos de permisos admitidos
Código de autorización: sí
Implícito
Credenciales: recurso, propietario, contraseña
Credenciales del cliente
Autorización JWT
Tipos de respuestas admitidas
codigo
id_token
clave id_token
ficha
Tipo de autorización: simple

Pestaña Credenciales de cliente: rellenado automáticamente

Pestaña de información del cliente:
URL de lanzamiento:
Pantalla de inicio de sesión
Nombre del cliente
URL del logotipo
URL de la página de inicio del cliente
URL de política
Términos de URL de servicio

2-1 Configuración del enlace en el cliente del servidor OAuth

Administración del sistema >> Seguridad >> OAuth 2.0 >> Cliente



Crear una descripción del servidor:
Punto final del generador: tome de los parámetros generales del servidor, ver arriba
Configuración SSL / TLS: seleccione de la lista de preconfigurados

El contenido de los campos restantes se descargará automáticamente del servidor, pero también puede configurarlos manualmente:

Servidor de autorizaciones
Punto final de autorización: CTG + / autorizar
Punto final clave: CTG + / token
Punto final de información del usuario: CTG + / userinfo
Punto final clave del autodiagnóstico: CTG + / revocación
Punto final de revocación clave: CTG + / introspección
Configuración de token web JSON (JWT)
Otra fuente además del registro dinámico: seleccione JWKS de URL
URL: CTG + / jwks



De esta lista, por ejemplo, se puede ver (scopes_supported y Claim_supported) que el servidor puede proporcionar información diferente sobre el usuario al cliente OAuth. Y vale la pena prestar atención a que al implementar su aplicación, deberá preguntarle al usuario qué datos está listo para compartir. Además, en nuestro ejemplo, solo se nos pedirá permiso por alcance1.

Guardar.

Si hay un error que indica SSL, vaya a la configuración:
Administración del sistema >> Seguridad >> Configuración SSL / TSL

2-2 Configuración del cliente OAuth

Administración del sistema >> Seguridad >> OAuth 2.0 >> Cliente >> Configuración del cliente >> Crear configuración del cliente



Pestaña general:
Nombre de la aplicación: cliente de demostración
Nombre del cliente: cliente de demostración
Descripción: opcional
Habilitado: sí
Tipo de cliente: confidencial
Configuración SSL / TCL: oauthclient
URL de redireccionamiento del cliente: nombre DNS de su servidor
Tipos de permisos requeridos
Código de autorización: sí
Implícito
Credenciales: recurso, propietario, contraseña
Credenciales del cliente
Autorización JWT
Tipo de autorización: simple

Pestaña de información del cliente:
Pantalla de inicio de sesión
URL del logotipo
URL de la página de inicio del cliente
URL de política
Términos de URL de servicio
Volumen predeterminado: tomamos de los especificados anteriormente en el servidor, por ejemplo, scope1
Direcciones de correo electrónico de contacto (separadas por una coma)
Edad máxima predeterminada (en segundos)

Pestaña de configuración de JWT:
Configuración de token web JSON (JWT)
Creación de configuraciones JWT a partir de credenciales X509
ID Algoritmos Tomados
Firma: RS256
Cifrado: A256CBC
Clave: RSA-OAEP
Algoritmos de información de usuario
Algoritmos de token de acceso
Algoritmos de consulta

Pestaña Credenciales de cliente:
Id cliente: del emitido tras el registro del cliente en el servidor (ver arriba)
Identificación del cliente emitida
Secreto del cliente: del que se emitió al registrar al cliente en el servidor (ver arriba)
El secreto del cliente caduca
URI de registro de cliente

Guardar.

Parte 4. Código

Creemos una aplicación web minimalista con autorización OAuth y REST.

Al trabajar, OAuth se basa en el hecho de que los canales de comunicación entre los participantes en la interacción (servidor, clientes, aplicación web, navegador de usuario, servidor de recursos) están de alguna manera protegidos. La mayoría de las veces, SSL / TLS desempeña este papel. Pero OAuth también trabajará en canales inseguros. Por ejemplo, el servidor Keycloak, por defecto, usa el protocolo HTTP y no tiene protección. Esto simplifica el desarrollo y la depuración durante el desarrollo. Con el uso real de los servicios de OAuth, la protección del canal debe estar estrictamente habilitada; esto se registra en la documentación de Keycloak. Los desarrolladores de IRIS de InterSystems adoptan un enfoque más riguroso para OAuth: se requiere SSL / TSL. La única simplificación es que puede usar certificados autofirmados o el servicio PKI integrado en IRIS (Administración del sistema >> Seguridad >> Sistema de clave pública).

La autorización del usuario se verifica con la indicación explícita de dos parámetros: el nombre de su aplicación y el volumen admitido por el servidor OAuth y en el cliente OAuth (alcance: ¿me pregunto cómo nombrarlo correctamente en ruso?):

Parameter OAUTH2APPNAME = "OAuthClient"; set isAuthorized = ##class(%SYS.OAuth2.AccessToken).IsAuthorized( ..#OAUTH2APPNAME, .sessionId, "scope1", .accessToken, .idtoken, .responseProperties, .error) 

En ausencia de autorización, estamos preparando un enlace a una solicitud de identificación de usuario y obteniendo su permiso para trabajar con nuestra aplicación. Aquí necesitamos indicar no solo el nombre de la aplicación y el volumen (alcance) solicitado registrado en el servidor OAuth y en el cliente OAuth, sino también un enlace de retroceso al que la aplicación web debería devolver al usuario.

 Parameter OAUTH2CLIENTREDIRECTURI = "https://52773b-76230063.labs.learning.intersystems.com/oauthclient/" set url = ##class(%SYS.OAuth2.Authorization).GetAuthorizationCodeEndpoint( ..#OAUTH2APPNAME, "scope1", ..#OAUTH2CLIENTREDIRECTURI, .properties, .isAuthorized, .sc) 

Utilizamos el servicio de autenticación IRIS incorporado y, en consecuencia, registramos a los usuarios en el servidor OAuth IRIS. Por ejemplo, es suficiente establecer al usuario solo un nombre de usuario y contraseña, no necesitará realizar otras configuraciones en la cuenta.

Al transferir al usuario utilizando el enlace recibido, el servidor llevará a cabo el procedimiento de identificación del usuario y le solicitará permiso para operar con credenciales en la aplicación web, y también guardará el resultado en su OAuth2.Server.Session global en el área% SYS:





3. Demostrar los datos de un usuario autorizado. Al completar con éxito los procedimientos, tenemos, por ejemplo, un token de acceso. Vamos a entenderlo:

 set valid = ##class(%SYS.OAuth2.Validation).ValidateJWT( .#OAUTH2APPNAME, accessToken, "scope1", .aud, .JWTJsonObject, .securityParameters, .sc ) 

Si es necesario, habilite los mensajes de depuración extendida en el servidor OAuth y el cliente OAuth. Los mensajes se escriben en el ISCLOG global en el área% SYS. Escriba su terminal IRIS (o instale y use un terminal web ):

 set ^%ISCLOG = 5 set ^%ISCLOG("Category", "OAuth2") = 5 set ^%ISCLOG("Category", "OAuth2Server") = 5 

Consulte la documentación de IRIS Uso de OAuth 2.0 y OpenID Connect para obtener más información .

Conclusiones:

1. OAuth ayuda a separar física y geográficamente los servicios con credenciales de usuario y bases de datos "en funcionamiento". Y, por lo tanto, fortalecer la protección de los datos de identificación y, si es necesario, cumplir con los requisitos de las leyes sobre protección de datos personales de diferentes países.
2. Con OAuth, puede proporcionar al usuario la capacidad de trabajar de manera segura de manera simultánea desde múltiples dispositivos y "brillar" mínimamente sus datos personales a diversos servicios y aplicaciones. Además de no tomar información "redundante" sobre los usuarios en sus servicios, es decir, llevar a cabo el procesamiento de datos despersonalizados en sus servicios.
3. Cuando utiliza InterSystems IRIS, tiene un conjunto completo de herramientas listas para probar y desplegar servicios OAuth y OIDC, tanto independientes como en cooperación con productos de software de terceros.

¿Qué industrias usan más comúnmente la plataforma InterSystems IRIS?
Para la automatización de la salud, en el sector financiero, para proyectos de gobierno electrónico, en logística, comercio minorista y muchas otras industrias.

Si está interesado en las tareas de automatización de la atención médica, preste atención al estándar FHIR. InterSystems IRIS for Health (una versión especial de la plataforma InterSystems IRIS) tiene soporte para el estándar FHIR para integración y desarrollo de aplicaciones

Como puede ver arriba, todas las características de OAuth son fácilmente accesibles y están completamente listas para usar. Si es necesario, puede reemplazar las clases de controlador y las interfaces de usuario con las suyas propias. El servidor OAuth y la configuración del cliente pueden realizarse a partir de archivos de configuración, en lugar de utilizar el portal de administración.