Approbation des protocoles de confiance - Authentification OAuth avec InterSystems IRIS

Comment permettre aux ordinateurs de se faire confiance en votre absence, tout en préservant la sécurité et la confidentialité?



- Martini sec. Dans un grand verre.
- Oui, monsieur. [Oui, Monsieur (Fr.)]
"Juste une seconde, pas tous." Trois doigts de Gordon, un de vodka, demi-doigt de Kina Lyklet. Bien battre dans un shaker, puis mettre une grosse tranche de citron. Tu te souviens?

Jan Fleming, Casino Royale, 1953

Partie 1. Histoires d'OAuth 2.0 et d'OpenID Connect

Universel et, semble-t-il, aujourd'hui au 21e siècle, le groupe préféré de protocoles de délégation et d'authentification en accès libre s'appelle OAuth + OIDC. Mieux pour une utilisation de masse jusqu'à présent, n'ont rien trouvé. Ils sont particulièrement populaires auprès des fournisseurs frontaux car ils marchent au-dessus des protocoles HTTP (S) et utilisent le conteneur JWT ( JSON Web Token ). OpenID Connect utilise OAuth pour son travail ou, en d'autres termes, OIDC est un wrapper pour OAuth.

OpenID - un standard ouvert pour l'authentification et la création de systèmes d'identification numérique n'est pas nouveau pour les développeurs. Cette année, il fête ses 14 ans. Dans la troisième version actuelle, le nom complet est OpenID Connect ou plus court que OIDC. Il est populaire à la fois dans le développement Web et mobile et dans les systèmes d'entreprise.

Son partenaire, l'OAuth Open Access Délégation Standard, a 12 ans. Et 9 ans après l'apparition de la norme RFC 5849. Nous nous appuierons sur la version moderne du protocole OAuth 2.0 et la RFC 6749 actuelle. N'oubliez pas qu'OAuth 2.0 n'est pas compatible avec son prédécesseur OAuth 1.0.

OAuth - un protocole ouvert (schéma, transport) pour déléguer l'accès, qui permet de fournir aux tiers un accès limité aux ressources protégées de l'utilisateur sans avoir à leur transférer (tiers) le login et le mot de passe de la RFC 6749

oauth.net est le premier site Web OAuth hébergé par Aaron Parecki

oauth.com - Tutoriel OAuth et environnement de test

Open ID Connect (OIDC) est une norme ouverte pour les systèmes d'identification décentralisés qui permet à l'utilisateur de créer un compte unique pour l'identification sur une variété de ressources Internet non liées à l'aide de services tiers, utilise des messages OAuth et un conteneur JWT pour une communication sécurisée.

À strictement parler, OAuth n'est pas un protocole, mais un ensemble de règles (schéma) pour séparer et transférer les opérations d'identification des utilisateurs vers un serveur de confiance distinct lors de la mise en œuvre de l'architecture de délimitation du contrôle d'accès dans les systèmes logiciels.

Et, attention, OAuth ne peut rien dire sur un utilisateur spécifique ! Ni qui il est, ni où il est maintenant, ni même s'il travaille sur l'ordinateur maintenant ou non. Mais ensuite, il permet d'interagir avec des systèmes sans intervention de l'utilisateur, en utilisant des jetons d'accès déjà émis. Ceci est un point important.

Cela peut être utile:

• OAuth se combine parfaitement avec l'utilisation du langage de description d'accès aux attributs XACML
• OAuth s'appuie également sur l'accès géré par l' utilisateur ( UMA )

L'utilisation conjointe d'OAuth + OIDC + UMA permet la mise en œuvre de systèmes d'identification et de contrôle d'accès sécurisés (Identity and Access Management - IdM, IAM) dans différents domaines, par exemple:

• en utilisant le profil HEART (Health Relationship Trust) des données personnelles d'un patient en médecine
• sur les plateformes d'identification client CIAM (Consumer Identity and Access Management) pour les entreprises de fabrication et de négoce
• personnalisation des certificats numériques des appareils intelligents dans les systèmes IoT (Internet of Things)

Un nouveau contrôle d'accès pour l'économie des API

Plus important encore, ne stockez pas de données personnelles au même endroit que le reste du système. Authentification et autorisation physiques distinctes. Et encore mieux - donnez toutes les pièces d'identité personnellement à la personne et ne la gardez jamais avec vous. Faites confiance au propriétaire de l'appareil.

Apple a déclaré quelles données personnelles les Russes stockent en Russie. Il s'agit du nom, de l'adresse, de l'e-mail, du numéro de téléphone. Mais les messages, les photos, etc., les gens eux-mêmes font confiance au cloud iCloud (qui n'est pas en Russie).

Partie 2. Lecture courte "Confiance et authentification"

Nous avons donc décidé qu'il n'était pas comme il faut de stocker les données personnelles de nos chers utilisateurs ni dans notre application, ni dans un seul stockage avec une base de données fonctionnelle. Autrement dit, ils ont choisi un fiduciaire fiable qui nous fournira ce service. Et donc, lorsque Sa Majesté l'Utilisateur apparaît, alors nous fournissons le dialogue suivant.

Acteurs:

• Utilisateur
• Application client
• Service d'identité
• Serveur de ressources

L'action se déroule dans un navigateur sur l'ordinateur de l'utilisateur. Tous les personnages se connaissent depuis longtemps. L'utilisateur dispose d'un compte personnel sur le service d'identité. L'application cliente a un contrat valide signé avec le service d'identification et les interfaces mutuelles. Le serveur de ressources fait confiance au service d'identité dans la question de la délivrance des clés d'accès à toute victime qu'il peut identifier.

Utilisateur (P): (en lançant une application client Web) Cher client, j'ai besoin de «cette ressource».
Application client (K): Cher utilisateur, présentez d'abord la clé de "cette ressource". Sans clé, l'accès à "cette ressource" est fermé.
P: Je n'ai pas une telle clé.
K: Ensuite, je vais temporairement vous transférer vers un service d'identification avec lequel nous avons un accord pour délivrer des clés au serveur de ressources. (redirige P. vers le service d'identification)
Service d'identification (I): Cher utilisateur, dites-moi qui vous êtes et quelles clés vous avez besoin?
P: Moi, Ytsuken User User, le mot de passe est tel ou tel, je veux avoir accès à "cette ressource".
Et: Merci, camarade Jtsuken. L'authentification a réussi et votre identification est vérifiée. Voici la clé de «cette ressource» (P. redirige vers K.)
P: Client, je vous ai apporté la clé de la «ressource» dont j'ai besoin.
K: Merci utilisateur. La clé est correcte. Voici la "ressource" que vous avez demandée.

Le rideau. La symphonie d'ouverture de Richard Strauss du film "Space Odyssey de 2001" joue

Partie 3. Service d'autorisation réel

Passons maintenant aux choses sérieuses. Nous avons trois tâches à l'ordre du jour: nommer les personnages, préparer la scène et jouer la pièce. Et tout est décidé en même temps sur la plateforme InterSystems IRIS. Mais ce n'est pas nécessaire, vous pouvez assembler un design à partir de différentes plateformes à votre discrétion. Par exemple, dans cette combinaison: serveur OAuth Keycloak + client OAuth et ressource OAuth sur IRIS. En d'autres termes:

1. Configurez et lancez le serveur OAuth avec l'enregistrement de notre client de démonstration dessus.
2. Configurez un client de démonstration OAuth en le connectant au serveur OAuth et aux ressources Web.
3. Développer des applications clientes pouvant utiliser OAuth. Vous pouvez utiliser Java, Python, C #, NodeJS. Voici un exemple de code d'application dans ObjectScript.

Le site Web de la communauté des développeurs contient une instruction détaillée de Daniel Kutak en trois parties avec des exemples d'utilisation d'OAuth dans IRIS pour différentes applications basées sur CSP ( partie 1 , partie 2 , partie 3 ).

Il existe de nombreux paramètres dans OAuth. Par conséquent, écrivez-vous des listes de contrôle - c'est l'application la plus appropriée pour eux. Exemples et blancs ci-dessous.

Où obtenir InterSystems IRIS prêt à l'emploi pour un échantillon? Il y a au moins deux options disponibles pour tout le monde:

Obtenez un serveur IRIS cloud préconfiguré prêt à l'emploi sur la plate-forme de formation InterSystems Learning Services dans la section InterSystems Learning Labs.

Installez un conteneur docker prêt à l'emploi . En savoir plus dans l'article - une instruction étape par étape pour les débutants du lancement d'IRIS à l'aide de développeurs Docker ou, qui préfèrent une vidéo, une instruction de capture d' écran de développement de solutions avec InterSystems IRIS à l'aide de Docker et VSCode

1-1 Configuration du serveur OAuth

Nous allons dans le portail de gestion IRIS et sélectionnons la section:

Administration système >> Sécurité >> OAuth 2.0 >> Serveur

Ensuite, dans chaque paragraphe, il y aura un nom pour la ligne des paramètres et, à travers les deux points, un exemple ou une explication si nécessaire.



Onglet Paramètres généraux:
Description: facultatif, par exemple, donc "Serveur d'autorisation"
Le point de terminaison du générateur (ci-après CTG) est le nom d'hôte: nom DNS de votre serveur
Types d'autorisation pris en charge (sélectionnez au moins un):
Code d'autorisation
Implicite
Informations d'identification: ressource, propriétaire, mot de passe
Identifiants client
Configuration SSL / TLS: oauthserver

Onglet Autorisations:
ajouter des volumes pris en charge: par exemple, scope1 et scope2

Onglet Intervalles:
Intervalle de clé d'accès: 3600
Intervalle de code d'autorisation: 60
Intervalle de mise à jour des clés: 86400
Intervalle d'interruption de session: 86400
Période de validité de la clé client: 0

Onglet Paramètres JWT:
Algorithme d'entrée: RS512
Algorithme de gestion des clés: RSA-OAEP
Algorithme de chiffrement de contenu: A256CBC-HS512

Onglet Personnalisation:
Identifier la classe:% OAuth2.Server.Authenticate
Vérifier la classe d'utilisateurs:% OAuth2.Server.Validate
Classe de service de session: OAuth2.Server.Session
Générer une classe de clés:% OAuth2.Server.JWT
Espace de noms de personnalisation:% SYS
Rôles de personnalisation (sélectionnez au moins un):% DB_IRISSYS et% Manager

Enregistrez.

1-2 Enregistrer le client sur le serveur OAuth

Bouton Description du client >> Bouton Créer une description du client:

Onglet Paramètres généraux:
Nom: CLIENT
Description: arbitraire
Type de client: confidentiel
URL de redirection: l'adresse du point de retour dans notre application après l'authentification
Types d'autorisations pris en charge
Code d'autorisation: oui
Implicite
Informations d'identification: ressource, propriétaire, mot de passe
Identifiants client
Autorisation JWT
Types de réponses pris en charge
code
id_token
clé id_token
jeton
Type d'autorisation: Simple

Onglet Informations d' identification du client: rempli automatiquement

Onglet Informations client:
URL de lancement:
Écran de connexion
Nom du client
URL du logo
URL de la page d'accueil du client
URL de stratégie
Conditions d'URL de service

2-1 Configuration de la liaison sur le client du serveur OAuth

Administration système >> Sécurité >> OAuth 2.0 >> Client



Créez une description de serveur:
Point de terminaison du générateur: prendre des paramètres généraux du serveur, voir ci-dessus
Configuration SSL / TLS: sélectionnez dans la liste des préconfigurés

Le contenu des champs restants sera téléchargé automatiquement à partir du serveur, mais vous pouvez également les configurer manuellement:

Serveur d'autorisation
Point de terminaison d'autorisation: CTG + / authorize
Point de terminaison clé: CTG + / token
Point de terminaison des informations utilisateur: CTG + / userinfo
Critère principal d'autodiagnostic: CTG + / révocation
Critère principal de révocation: CTG + / introspection
Paramètres de jeton Web JSON (JWT)
Autre source que l'enregistrement dynamique: sélectionnez JWKS dans l'URL
URL: CTG + / jwks



À partir de cette liste, par exemple, on peut voir (scopes_supported et claims_supported) que le serveur peut fournir au client OAuth différentes informations sur l'utilisateur. Et il vaut la peine de faire attention lors de la mise en œuvre de votre application, vous devrez demander à l'utilisateur quelles données il est prêt à partager. De plus, dans notre exemple, nous ne demanderons l'autorisation que par scope1.

Enregistrez.

S'il y a une erreur indiquant SSL, alors allez dans les paramètres:
Administration système >> Sécurité >> Configuration SSL / TSL

2-2 Configuration du client OAuth

Administration système >> Sécurité >> OAuth 2.0 >> Client >> Configuration client >> Créer une configuration client



Onglet Général:
Nom de l'application: client de démonstration
Nom du client: client de démonstration
Description: facultatif
Activé: Oui
Type de client: confidentiel
Configuration SSL / TCL: oauthclient
URL de redirection client: nom DNS de votre serveur
Types d'autorisation requis
Code d'autorisation: oui
Implicite
Informations d'identification: ressource, propriétaire, mot de passe
Identifiants client
Autorisation JWT
Type d'autorisation: Simple

Onglet Informations client:
Écran de connexion
URL du logo
URL de la page d'accueil du client
URL de stratégie
Conditions d'URL de service
Volume par défaut: nous prenons ceux spécifiés précédemment sur le serveur, par exemple scope1
Adresses e-mail de contact (séparées par une virgule)
Âge maximum par défaut (en secondes)

Onglet Paramètres JWT:
Paramètres de jeton Web JSON (JWT)
Création de paramètres JWT à partir des informations d'identification X509
Algorithmes IDToken
Signature: RS256
Cryptage: A256CBC
Clé: RSA-OAEP
Algorithmes Userinfo
Algorithmes de jeton d'accès
Algorithmes de requête

Onglet Informations d'identification du client:
Id client: à partir de celui émis lors de l'enregistrement du client sur le serveur (voir ci-dessus)
Identifiant client émis
Secret du client: celui émis lors de l'enregistrement du client sur le serveur (voir ci-dessus)
Le secret client expire
URI d'enregistrement du client

Enregistrez.

Partie 4. Code

Créons une application web minimaliste avec autorisation OAuth et REST.

En travaillant, OAuth s'appuie sur le fait que les canaux de communication entre les participants à l'interaction (serveur, clients, application web, navigateur utilisateur, serveur de ressources) sont en quelque sorte protégés. Le plus souvent, ce rôle est joué par SSL / TLS. Mais OAuth fonctionnera également sur les canaux non sécurisés. Par exemple, le serveur Keycloak, par défaut, utilise le protocole HTTP et va sans protection. Cela simplifie le développement et le débogage pendant le développement. Avec l'utilisation réelle des services OAuth, la protection des canaux doit être strictement activée - cela est enregistré dans la documentation Keycloak. Les développeurs InterSystems IRIS adoptent une approche plus rigoureuse pour OAuth - SSL / TSL est requis. La seule simplification est que vous pouvez utiliser des certificats auto-signés ou utiliser le service PKI intégré à IRIS (Administration système >> Sécurité >> Système de clé publique).

L'autorisation de l'utilisateur est vérifiée avec l'indication explicite de deux paramètres - le nom de votre application et le volume pris en charge par le serveur OAuth et dans le client OAuth (portée - je me demande comment la nommer correctement en russe?):

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

En l'absence d'autorisation, nous préparons un lien vers une demande d'identification de l'utilisateur et obtenons de lui l'autorisation de travailler avec notre application. Ici, nous devons indiquer non seulement le nom de l'application et le volume demandé (étendue) enregistrés sur le serveur OAuth et dans le client OAuth, mais également un lien de retour vers lequel l'application Web doit renvoyer l'utilisateur.

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

Nous utilisons le service d'authentification IRIS intégré et, par conséquent, nous enregistrons les utilisateurs sur le serveur IRIS OAuth. Par exemple, il suffit de définir à l'utilisateur uniquement un nom d'utilisateur et un mot de passe, vous n'aurez pas besoin de faire d'autres réglages dans le compte.

Lors du transfert de l'utilisateur à l'aide du lien reçu, le serveur exécutera la procédure d'identification de l'utilisateur et lui demandera l'autorisation de fonctionner avec les informations d'identification dans l'application Web, et enregistrera également le résultat dans son global OAuth2.Server.Session dans la zone% SYS:





3. Démontrez les données d'un utilisateur autorisé. Une fois les procédures terminées, nous avons, par exemple, un jeton d'accès. Obtenons-le:

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

Si nécessaire, activez les messages de débogage étendus sur le serveur OAuth et le client OAuth. Les messages sont écrits dans le global ISCLOG dans la zone% SYS. Saisissez votre terminal IRIS (ou installez et utilisez un terminal Web ):

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

Consultez la documentation IRIS Utilisation d'OAuth 2.0 et d'OpenID Connect pour plus d'informations .

Conclusions:

1. OAuth permet de séparer physiquement et géographiquement les services avec les informations d'identification de l'utilisateur et les bases de données «fonctionnelles». Et, ainsi, renforcer la protection des données d'identification et, si nécessaire, se conformer aux exigences des lois sur la protection des données personnelles des différents pays.
2. En utilisant OAuth, l'utilisateur peut avoir la possibilité de travailler en toute sécurité à partir de plusieurs appareils en même temps et de «briller» ses données personnelles de manière minimale sur divers services et applications. En plus de ne pas prendre d'informations «redondantes» sur les utilisateurs de leurs services, c'est-à-dire d'effectuer un traitement de données dépersonnalisé dans leurs services.
3. Lorsque vous utilisez InterSystems IRIS, vous disposez d'un ensemble complet d'outils prêts à l'emploi pour tester et déployer les services OAuth et OIDC de manière autonome et en coopération avec des produits logiciels tiers.

Quelles industries utilisent le plus souvent la plate-forme InterSystems IRIS?
Pour l'automatisation des soins de santé, dans le secteur financier, pour les projets de gouvernement électronique, dans la logistique, le commerce de détail et de nombreuses autres industries.

Si vous êtes intéressé par les tâches d'automatisation des soins de santé, faites attention à la norme FHIR. InterSystems IRIS for Health (une version spéciale de la plate-forme InterSystems IRIS) prend en charge la norme FHIR pour l'intégration et le développement d'applications

Comme vous pouvez le voir ci-dessus, toutes les fonctionnalités OAuth sont facilement accessibles et entièrement prêtes à l'emploi. Si nécessaire, vous pouvez remplacer les classes de gestionnaire et les interfaces utilisateur par les vôtres. Les paramètres du serveur et du client OAuth peuvent être définis à partir des fichiers de configuration, au lieu d'utiliser le portail de gestion.