La sécurité dans le domaine informatique est la protection des systèmes informatiques contre le vol et la détérioration du matériel, des logiciels ou des informations, ainsi que contre l'interruption ou la perturbation des services fournis.
Consultez la documentation d'InterSystems sur la sécurité.
Restez en contact avec InterSystems et recevez rapidement des alertes, des avis et des actualités sur les produits. Le processus est vraiment simple :
Comme vous pouvez le constater, il faut moins d'une minute pour se tenir informé de l'actualité !
Chez InterSystems, nous croyons en la divulgation responsable des vulnérabilités de sécurité récemment découvertes. Nous fournissons des informations opportunes à nos clients, tout en les gardant hors de la portée des personnes susceptibles d'en faire un mauvais usage. Nous comprenons également que chaque client a des exigences différentes liées à la résolution des problèmes de sécurité.
Alors que nous commençons 2023, nous avons apporté deux changements importants à notre approche des corrections des failles de sécurité que je voudrais souligner :
Si vous souhaitez essayer le nouveau processus d'installation du projet NoPWS, vous pouvez accéder à l'Early Access Program (EAP) here.
Une fois inscrit, veuillez envoyer à InterSystems l'adresse e-mail que vous avez utilisée pour vous inscrire à l'EAP à nopws@intersystems.com.
Regardez ici pour en savoir plus : message original
Lors de la création d’un PRA (Privileged Routine Application; qui d’ailleurs n’est pas pertinent uniquement pour les routines mais aussi pour les classes/méthodes), il est important de s’assurer d’inclure un new $ROLES, avant d’appeler AddRoles(). Par exemple:
New $ROLES
set status=$System. Security.AddRoles(« MyPrivilegedRoutineApplication »)
De cette façon, vous vous assurez que les rôles ajoutés (élevés) « s’évaporent » pour l’utilisateur exécutant ce code, une fois que l’utilisateur est hors du champ d’application de cette routine / méthode.
[Merci @Andreas Dieckow d’avoir validé cela]
Hourra pour la sécurité !
Si vous vous connectez à un serveur local et effectuez un développement isolé avec un compte jetable, stockez simplement votre mot de passe en texte brut dans le fichier de configuration settings.json. Mais si vous travaillez avec un serveur partagé en utilisant un "vrai" compte d'utilisateur, c'est une bonne idée de protéger ces informations.
Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.
Dans la première partie, nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services.
La deuxième partie discute et montre en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès présent dans la demande entrante et transmettre la demande au backend si la validation réussit.
Cette dernière partie de cette série abordera et démontrera les configurations nécessaires pour que IAM génère un jeton d'accès (agissant comme un serveur d'autorisation) et le valide, ainsi que quelques considérations finales importantes.
Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems.
Dans ce scénario, contrairement au premier scénario, nous allons utiliser un plugin appelé "OAuth 2.0 Authentication".
Afin d'utiliser IAM comme serveur d'autorisation dans ce flux d'informations d'identification du propriétaire des ressources et du mot de passe, le nom d'utilisateur et le mot de passe doivent être authentifiés par l'application cliente. La demande d'obtention du jeton d'accès auprès d'IAM ne doit être effectuée que si l'authentification est réussie.
Commençons par l'ajouter à notre "SampleIRISService". Comme vous pouvez le voir dans la capture d'écran ci-dessous, nous avons différents champs à remplir afin de configurer ce plugin.
.png)
Tout d'abord, nous allons copier l'identifiant de notre service "SampleIRISService" dans le champ "service_id" pour activer ce plugin à notre service.
Dans le champ "config.auth_header_name", nous allons spécifier le nom de l'en-tête qui portera le jeton d'autorisation. Dans ce cas, je vais laisser la valeur par défaut comme "authorization".
Le plugin "OAuth 2.0 Authentication" prend en charge les flux OAuth 2.0 Authorization Code Grant, Client Credentials, Implicit Grant ou Resource Owner Password Credentials Grant (respectivement, Attribution de codes d'autorisation, Identifiants client, Attribution implicite et Attribution des informations d'identification du mot de passe du propriétaire de la ressource OAuth 2.0). Comme nous utilisons dans cet article le flux "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource), nous allons cocher la case "config.enable_password_grant"..
Dans le champ "config.provision_key", saisissez une chaîne à utiliser comme clé de provision. Cette valeur sera utilisée pour demander un jeton d'accès à IAM.
Dans ce cas, j'ai laissé tous les autres champs avec la valeur par défaut. Vous pouvez vérifier la référence complète de chaque champ dans la documentation du plugin disponible ici.
Voici à quoi ressemble la configuration du plugin à la fin :
.png)
Une fois le plugin créé, nous devons créer les informations d'identification de notre consommateur "ClientApp".
Pour ce faire, allez dans "Consumers" dans le menu de gauche et cliquez sur "ClientApp". Ensuite, cliquez sur l'onglet "Credentials" et ensuite sur le bouton "New OAuth 2.0 Application".
.png)
Sur la page suivante, entrez un nom quelconque pour identifier votre application dans le champ "name" (nom), définissez un identifiant et un secret de client, respectivement, dans les champs "client_id" et "client_secret" et enfin, entrez l'URL dans votre application où les utilisateurs seront envoyés après autorisation dans le champ "redirect_uri". Ensuite, cliquez sur "Create" (créer).
.png)
Maintenant, vous êtes prêt à envoyer des demandes.
La première requête que nous devons faire est d'obtenir le jeton d'accès depuis IAM. Le plugin "OAuth 2.0 Authentication" crée automatiquement un point de terminaison en ajoutant le chemin "/oauth2/token" à l'itinéraire déjà créé.
Par conséquent, dans ce cas, nous devrions faire une demande POST à l'URL :
https://iamhost:8443/event/oauth2/token
Dans le corps de la requête, vous devez inclure le JSON suivant :
{ "client_id": "clientid", "client_secret": "clientsecret", "grant_type": "password", "provision_key": "provisionkey", "authenticated_userid": "1"}Comme vous pouvez le constater, ce JSON contient des valeurs définies à la fois lors de la création du plugin "OAuth 2.0 Authentication", telles que "grant_type" et "provision_key", et lors de la création des informations d'identification du Consommateur, telles que "client_id" et "client_secret".
Le paramètre "authenticated_userid" doit également être ajouté par l'application client lorsque le nom d'utilisateur et le mot de passe fournis sont authentifiés avec succès. Sa valeur doit être utilisée pour identifier de manière unique l'utilisateur authentifié.
La demande et sa réponse respective devraient ressembler à ceci :
.png)
Avec cela, nous pouvons maintenant faire une requête pour obtenir les données de l'événement en incluant la valeur "access_token" de la réponse ci-dessus comme "Bearer Token" (jeton de porteur) dans une requête GET vers l'URL
.png)
Si votre jeton d'accès expire, vous pouvez générer un nouveau jeton d'accès en utilisant le jeton de renouvellement que vous avez reçu avec le jeton d'accès expiré en effectuant une requête POST vers le même point de terminaison que celui utilisé pour obtenir un jeton d'accès, avec un corps quelque peu différent :
{ "client_id": "clientid", "client_secret": "clientsecret", "grant_type": "refresh_token", "refresh_token": "E50m6Yd9xWy6lybgo3DOvu5ktZTjzkwF"}La demande et sa réponse respective devraient ressembler à ceci :
.png)
Une fonctionnalité intéressante du plugin "OAuth 2.0 Authentication" est la possibilité d'afficher et d'invalider les jetons d'accès.
Pour répertorier les tokens, envoyez une requête GET au point de terminaison suivant de l'API d'administration d'IAM :
https://iamhost:8444/{workspace_name}/oauth2_tokens
où {workspace_name} est le nom de l'espace de travail IAM utilisé. Veillez à saisir les informations d'identification nécessaires pour appeler l'API d'administration d'IAM si vous avez activé RBAC.
.png)
Notez que "credential_id" est l'identifiant de l'application OAuth que nous avons créée dans le consommateur ClientApp (dans ce cas, elle s'appelle SampleApp), et "service_id" est l'identifiant de notre "SampleIRISService" auquel ce plugin est appliqué.
Pour invalider un jeton, vous pouvez envoyer une demande DELETE au point de terminaison suivant
https://iamhost:8444/Sample/oauth2_tokens/{token_id}
où {token_id} est l'identifiant du jeton à invalider.
.png)
Si nous essayons d'utiliser le jeton invalidé, nous obtenons un message indiquant que le jeton est invalide ou a expiré si nous envoyons une requête GET contenant ce jeton invalidé comme jeton porteur à l'URL :
Dans cet article, nous avons montré comment vous pouvez ajouter l'authentification OAuth 2.0 dans IAM à un service non authentifié déployé dans IRIS. Vous devez tenir compte du fait que le service lui-même continuera à être non authentifié dans IRIS. Par conséquent, si quelqu'un appelle directement le point de terminaison du service IRIS, en contournant la couche IAM, il pourra voir les informations sans aucune authentification. Pour cette raison, il est important d'avoir des règles de sécurité au niveau du réseau pour empêcher les demandes non désirées de contourner la couche IAM.
Vous pouvez en savoir plus sur IAM ici.
Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems.
Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.
Dans la première partie, nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services.
Cette partie va maintenant discuter et montrer en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès présent dans la demande entrante et transmettre la demande au backend si la validation réussit.
La dernière partie de cette série abordera et démontrera les configurations nécessaires pour que IAM génère un jeton d'accès (agissant comme un serveur d'autorisation) et le valide, ainsi que quelques considérations finales importantes.
Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems.
Dans ce scénario, il sera utilisé un serveur d'autorisation externe qui génère un jeton d'accès au format JWT (JSON Web Token). Ce JWT est signé à l'aide de l'algorithme RS256 et d'une clé privée. Afin de vérifier la signature du JWT, l'autre partie (dans ce cas IAM) doit avoir la clé publique, fournie par le serveur d'autorisation.
Ce JWT généré par le serveur d'autorisation externe comprend également, dans son corps, une déclaration appelée "exp" contenant l'horodatage de la date d'expiration de ce jeton, et une autre déclaration appelée "iss" contenant l'adresse du serveur d'autorisation.
Par conséquent, IAM doit vérifier la signature du JWT avec la clé publique des serveurs d'autorisation et l'horodatage d'expiration contenu dans la déclaration "exp" à l'intérieur du JWT avant de transmettre la demande à IRIS.
Afin de configurer cela dans IAM, commençons par ajouter un plugin appelé "JWT" à notre "SampleIRISService" dans IAM. Pour ce faire, allez sur la page Services dans IAM et copiez l'identifiant du "SampleIRISService", nous allons l'utiliser plus tard.
.png)
Ensuite, allez dans Plugins, cliquez sur le bouton "New Plugin", localisez le plugin "JWT" et cliquez sur Enable.
.png)
Dans la page suivante, copiez l'identifiant "SampleIRISService" dans le champ "service_id" et cochez la case "exp" dans le paramètre "config.claims_to_verify".
.png)
Notez que la valeur du paramètre "config.key_claim_name" est "iss". Nous allons l'utiliser plus tard.
Ensuite, appuyez sur le bouton "Create" (créer).
Cela fait, allez dans la section "Consumers" dans le menu de gauche et cliquez sur notre "ClientApp" précédemment créée. Allez dans l'onglet "Credentials" (identifiants) et cliquez sur le bouton “New JWT Credential” (nouveau Identifiants JWT).
.png)
Dans la page suivante, sélectionnez l'algorithme utilisé pour signer le JWT ( ici RS256) et copiez la clé publique dans le champ "rsa_public_key" (il s'agit de la clé publique qui vous a été fournie par le serveur d'autorisation au format PEM).
Dans le champ "key", vous devez insérer le contenu du revendication JWT que vous avez entré dans le champ "config.key_claim_name" lors de l'ajout du plugin JWT. Donc, dans ce cas, je dois insérer le contenu de la revendication iss de mon JWT, qui, dans mon cas, est l'adresse du serveur d'autorisation.
Après cela, cliquez sur le bouton "Créer".
Maintenant, avec l'ajout du plugin JWT, il n'est plus possible d'envoyer la requête sans authentification. Comme vous pouvez le voir ci-dessous, une simple demande GET, sans authentification, renvoie à l'URL
un message non autorisé avec le code de statut "401 Unauthorized".
Afin d'obtenir les résultats d'IRIS, nous devons ajouter le JWT à la requête.
Par conséquent, nous devons d'abord demander le JWT au serveur d'autorisation. Le serveur d'autorisation personnalisé que nous utilisons ici renvoie un JWT si une demande POST est faite avec quelques paires clé-valeur dans le corps, y compris des informations sur l'utilisateur et le client, à l'URL suivante :
https://authorizationserver:5001/auth
Voici à quoi ressemblent cette requête et sa réponse :
Ensuite, vous pouvez ajouter le JWT obtenu à partir de la réponse ci-dessous dans le header d'autorisation en tant que jeton de porteur Bearer Token et envoyer une requête GET à la même URL utilisée précédemment :
Vous pouvez également l'ajouter en tant que paramètre de chaîne de recherche, la clé de la chaîne de recherche étant la valeur spécifiée dans le champ "config.uri_param_names" lors de l'ajout du plugin JWT qui, dans ce cas, est "jwt" :
Enfin, il y a aussi la possibilité d'inclure JWT dans la requête en tant que cookie, si un nom est saisi dans le champ "config.cookie_names".
Passez à la troisième et dernière partie de cette série pour comprendre les configurations nécessaires pour générer un jeton d'accès IAM et le valider, ainsi que quelques considérations finales importantes.
Aujourd'hui, de nombreuses applications utilisent le cadre d'autorisation ouvert (OAuth) pour accéder aux ressources de toutes sortes de services de manière sûre, fiable et efficace. InterSystems IRIS est déjà compatible avec le cadre OAuth 2.0, en fait, il y a un excellent article dans la communauté concernant OAuth 2.0 et InterSystems IRIS dans le lien suivant ici.
Toutefois, avec l'avènement des outils de gestion des API, certaines organisations l'utilisent comme point unique d'authentification, empêchant les demandes non autorisées d'arriver aux services descendants et découplant les complexités d'autorisation/authentification du service lui-même.
Comme vous le savez peut-être, InterSystems a lancé son outil de gestion des API, appelé InterSystems API Management (IAM), qui est disponible avec la licence IRIS Enterprise (et non IRIS Community Edition). Vous trouverez ici un autre excellent article de la communauté présentant InterSystems API Management.
Il s'agit de la première partie d'une série d'articles en trois parties qui montrent comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.
Dans cette première partie, vous trouverez des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services.
Suite à la première partie, cette série d'articles abordera deux scénarios possibles pour sécuriser vos services avec IAM. Dans le premier scénario, IAM validera uniquement le jeton d'accès présent dans la requête entrante et transmettra la requête au backend si la validation réussit. Dans le second scénario, IAM va à la fois générer un jeton d'accès (en agissant comme un serveur d'autorisation) et le valider.
Par conséquent, la deuxième partie abordera et montrera en détail les étapes nécessaires pour configurer le scénario 1, et la troisième partie abordera et démontrera les configurations pour le scénario 2, ainsi que quelques considérations finales.
Si vous voulez essayer IAM, veuillez contacter votre représentant commercial InterSystems.
Chaque flux d'autorisation OAuth 2.0 se compose essentiellement de 4 parties :
Pour des raisons de simplicité, cet article utilisera le flux OAuth "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource), mais vous pouvez utiliser n'importe quel flux OAuth dans IAM. De même, cet article ne spécifiera aucune portée.
En général, le flux "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource) suit les étapes suivantes :
Dans cette optique, il existe deux scénarios dans lesquels vous pouvez utiliser IAM pour traiter OAuth 2.0 :
Dans ce post, il sera utilisé une application Web IRIS appelée "/SampleService". Comme vous pouvez le voir sur la capture d'écran ci-dessous, il s'agit d'un service REST non authentifié déployé dans IRIS :
.png)
En outre, dans le côté IAM est configuré un service appelé "SampleIRISService" contenant un itinéraire, comme vous pouvez le voir dans la capture d'écran ci-dessous :
.png)
En outre, dans IAM est configuré un consommateur appelé "ClientApp", initialement sans aucun justificatif d'identité, pour identifier celui qui appelle l'API dans IAM :
.png)
Avec les configurations ci-dessus, IAM transmet chaque requête GET envoyée à l'URL suivante à IRIS :
À ce stade, aucune authentification n'est encore utilisée. Par conséquent, si nous envoyons une simple requête GET, sans authentification, à l'URL
nous obtenons la réponse recherchée.
Dans cet article, nous allons utiliser une application appelée "PostMan" pour envoyer des requêtes et vérifier les réponses. Dans la capture d'écran de PostMan ci-dessous, vous pouvez voir une simple requête GET ainsi que sa réponse.
.png)
Passez à la deuxième partie de cette série pour comprendre comment configurer IAM pour valider les jetons d'accès présents dans les demandes entrantes.