Sécurité de l'API

Vous pouvez sécuriser vos API à l'aide de deux niveaux différents qui vous aident à contrôler qui peut appeler des API et quelle autorisation cette personne doit avoir.

Lors de l'appel d'une API, vous devez franchir les deux niveaux de sécurité suivants :

  1. Authentification avec un ID utilisateur, un certificat ou les deux. L'API de connexion est appelée avant l'appel de toute autre API.
  2. L'autorisation, qui vérifie l'API à laquelle vous pouvez accéder.

Cette procédure de sécurité concerne tous les appels d'API effectués via un processus de serveur d'applications. Par défaut, un agent et des serveurs d'intégration bénéficient toujours d'accès complet aux API.

Une fois le contrôle d'authentification franchi, une vérification d'autorisation détermine les API et les ressources auxquelles vous pouvez accéder. Cette vérification d'autorisation s'ajoute à la sécurité de l'interface utilisateur. Par exemple, la sécurité de l'interface utilisateur peut vous aider à accéder à un écran qui répertorie les utilisateurs. Pour générer une liste d'utilisateurs à l'écran, vous devrez peut-être également passer une vérification d'autorisation pour l'API getUserList qui répertorie les utilisateurs.

Voici d'autres exemple de vérifications d'autorisation :
  • Si vous utilisez l'API getCommonCodeList à des fins d'affichage, vous ne devez pas être en mesure d'obtenir des informations utilisateur qui sont explicitement restreintes à partir de la sortie de l'API.
  • Si vous appelez l'API getUserList avant d'affecter une alerte, vous ne devriez pas être en mesure d'obtenir des mots de passe utilisateur.
  • Si vous utilisez l'API UserHierarchy pour modifier votre mot de passe:
    • Vous ne devez pas pouvoir modifier votre propre indicateur IsSuperUser.
    • Vous ne devez pas pouvoir modifier les informations d'un autre utilisateur.
    • Vous ne devez pas être en mesure de vous abonner à d'autres groupes d'utilisateurs, ce qui vous donnerait plus d'accès au système.

Cette sécurité est implémentée à l'aide des fichiers modèle apisecurity. Ces fichiers modèles apisecurity sont des fichiers XML qui documentent les éléments d'entrée et de sortie pour lesquels (par défaut) toutes les API sont restreintes. Ces fichiers sont automatiquement générés lors du déploiement XAPI, même si la génération de documents est désactivée.

Remarque: les services n'utilisent pas le fichier apisecurity.

Les modèles sont utilisés pour les vérifications d'autorisation d'entrée et de sortie. Ils remplacent les modèles standard.

Par exemple, un modèle d'entrée avec les lignes OrganizationCode=#PROHIBITED# et IsSuperUser=#PROHIBITED# vous empêcherait de vous abonner à plus de groupes d'utilisateurs et d'obtenir plus de droits.

Le modèle de sortie complète le filtrage exécuté par le modèle par défaut basé sur la documentation. Si un élément est limité parce qu'il n'est pas configuré dans le fichier apisecurity, il ne sera jamais renvoyé dans la sortie, même s'il est présent dans le modèle basé sur la documentation.

Remarque: à certains points de l'entrée et de la sortie, les API telles que multiApi et getPage ont un accès d'autorisation pour n'importe quel élément. Cependant, d'autres API appelées par ces API doivent passer par la vérification d'autorisation.

Les accès à l'API de sécurité et au niveau d'accès sont contrôlés dans les propriétés suivantes du fichier yfs.properties. Tous les échecs d'autorisation sont consignés dans une catégorie de journal intitulée sci.apisecurity.

  • api.security.enabled
    • Y (par défaut) — Active une sécurité de l'API
    • N — N'active pas de sécurité de l'API
  • api.security.mode
    • STRICT - Génère une exception en cas d'échec de la validation. Approprié aux systèmes de production, si tous les droits d'accès sont correctement configurés.
    • LAX - Filtre et journalise une entrée non valide, tout en poursuivant le traitement. Le filtrage permet principalement au système de fonctionner malgré une entrée ou une sortie incorrecte, tandis que la consignation permet d'identifier les endroits nécessitant un changement.
      Remarque: le système peut toujours émettre une exception lorsque le filtrage génère un comportement ambigu.
    • DEBUG - Consignation d'une entrée et d'une sortie incorrecte, mais il n'y a pas de filtrage ni d'émission d'exception. Cela n'est approprié que lors du développement initial pour identifier les droits requis par les différents processus.

Si vous ne spécifiez pas de mode de sécurité, il n'existe alors aucun filtrage, aucune exception émise ni contrôle des autorisations. La consignation est alors limitée.

  • api.security.override .apiName.mode

    Ce paramètre permet de remplacer les autorisations sur des API individuelles. Cette propriété utilise les mêmes valeurs que api.security.mode.

  • api.security.smc.enabled
    • Y-Enable API security for Applications Manager
    • N (par défaut)-Ne pas activer la sécurité d'API pour Applications Manager
  • api.security.console.enabled
    • Y - Active la sécurité de l'API pour la console d'application
    • N (par défaut) - N'active pas la sécurité de l'API pour la console d'application

Lors d'une mise à niveau, vous devez d'abord désactiver cette fonction et lui accorder tous les accès via les propriétés. Dans un système mis à niveau, vous pouvez échelonner cette fonction en activant la sécurité sur une API à la fois, à mesure que vous définissez et testez les droits. Si cette option est activée, seul le groupe d'utilisateurs du système se voit accorder les droits aux API, pour tous les autres groupes d'utilisateurs personnalisés, une autorisation appropriée doit être donnée. Pour plus d'informations sur les droits des groupes d'utilisateurs, voir A propos de la modélisation d'organisation.