Différences

Ci-dessous, les différences entre deux révisions de la page.

--- si7:configuration:apirest [2021/02/28 12:07] – [Utilisation de diagrammes de séquence avec l'API REST] techer.charles_educ-valadon-limoges.fr
+++ si7:configuration:apirest [2021/03/04 19:09] (Version actuelle) – techer.charles_educ-valadon-limoges.fr
@@ Ligne 67: / Ligne 67: @@
 | PUT| Mettre à jour| Remplacer ou mettre à jour une ressource existante.
 | PATCH| Mise à jour partielle| Mettez à jour certains détails à partir d'une ressource existante.|
-| DEL| Supprimer| une ressource du système.|
+| DELETE| Supprimer| une ressource du système.|
    * **En-tête** : l'API REST utilise le format d'en-tête HTTP standard formaté en paires nom-valeur séparées par deux points ( : ), [name]:[value]. Des en-têtes HTTP standard sont utilisables ainsi des en-têtes personnalisés. Il Les en-têtes de requpete (de demande) incluent des informations supplémentaires qui ne sont pas liées au contenu du message.
@@ Ligne 112: / Ligne 112: @@
 L'interaction avec un service d'API REST particulier consiste en une séquence de demandes. Pour cette raison, les diagrammes de séquence sont fréquemment utilisés pour expliquer la requête/réponse de l'API REST et l'activité asynchrone.
 <uml>
-Client -> Serveur_HTTP/S : HTTP/S : créer une session avec accréditation
+==Requête GET==
-Serveur_HTTP/S -> Client : jeton d'accréditation
+Client -> Serveur_HTTP_S : HTTP/S : créer session\navec accréditation
-Client -> Serveur_HTTP/S : HTTP/S : GET liste des périphériques
+Serveur_HTTP_S -> Client : jeton\nd'accréditation
-Serveur_HTTP/S -> Service API : GET liste des périphériques
+Client -> Serveur_HTTP_S : HTTP/S : GET\nliste des périphériques
-==Préparation du serveur OpenVPN==
+Serveur_HTTP_S -> Service_API : GET\nliste des périphériques
+Service_API -> BDDConfiguration : Fetch\nliste des périphériques
+BDDConfiguration -> Service_API : Réponse\nliste des périphériques
+Service_API -> Serveur_HTTP_S : Réponse\nliste des périphériques
+Serveur_HTTP_S -> Client : HTTP/S Réponse\nliste des périphériques\nCode réponse 200\nSuccess
+==Requête POST en asynchrone==
+Client -> Serveur_HTTP_S : HTTP/S : POST\nAjout équipement X
+Serveur_HTTP_S -> Service_API : ADD\nAjout équipement X
+Service_API -> Coeur_app : initiation\najout équipement
+Coeur_app -> Service_API : Réponse\nID de la tâche
+Service_API -> BDDConfiguration : ADD\nAjout équipement X
+Service_API -> Client : HTTP/S : réponse ID de la tâche\nCode réponse 2020 (accepted)
+BDDConfiguration -> Service_API : \nEcriture faite
+Service_API -> Serveur_HTTP_S : \nEcriture faite\navec succès
+Serveur_HTTP_S -> Client : HTTP/S Réponse\nliste des périphériques
 </uml>
+===== Authentification à une API REST =====
+Pour des raisons de sécurité, la plupart des API REST nécessitent une authentification afin que les utilisateurs aléatoires ne puissent pas créer, mettre à jour ou supprimer des informations de manière incorrecte ou malveillante, ou accéder à des informations qui ne devraient pas être publiques. La nécessité d'une authentification est le même concept que l'exigence d'un nom d'utilisateur/mot de passe pour accéder à la page d'administration d'une application.
+Des API qui ne nécessitent pas d'authentification sont généralement en lecture seule et ne contiennent pas d'informations critiques ou confidentielles.
+**L'authentification** permet de **prouver l’identité** du client.
+**L'autorisation** définit **l’accès** du client à des données.
+==== Mécanismes d'authentification ====
+Les types courants de mécanismes d'authentification incluent Basic, Bearer et API Key.
+=== Authentification de base ===
+Cette authentification utilise le schéma d'authentification HTTP de base standard en transmettant les informations d'identification sous forme de **paires nom d'utilisateur/mot de passe** séparées par un deux-points ( : ) et encodées à l'aide de Base64.
+C'est le mécanisme d'authentification le plus **simple** mais est extrêmement **peu sécurisé** à moins qu'il ne soit jumelé avec des requêtes utilisant HTTPS plutôt que HTTP. Bien que les informations d'identification soient encodées, elles ne sont **pas chiffrées**. Il est simple de décoder les informations d'identification et d'obtenir la paire nom d'utilisateur/mot de passe.
+<WRAP center round info>
+Dans une requête d'API REST, les informations d'authentification de base seront **fournies dans l'en-tête**:
+<code>
+Authorization: Basic <username>:<password>
+</code>
+</WRAP>
+=== Authentification du porteur ===
+Ce mécanisme d'authentification appelé aussi **authentification au jeton**, utilise le schéma d'authentification HTTP au porteur standard. Il est **plus sécurisé** que l'authentification de base et est généralement utilisé avec **OAuth** et **Single Sign-On (SSO)**. L'authentification au porteur utilise un jeton porteur, qui est une chaîne générée par un **serveur d'authentification externe** tel qu'un service d'identité (ID).
+<WRAP center round info>
+Tout comme l'authentification de base, l'authentification au porteur doit être utilisée avec HTTPS.
+Dans une requête d'API REST, les informations d'authentification du porteur seront fournies dans l'en-tête :
+<code>
+Authorization: Bearer <bearer token>
+</code>
+</WRAP>
+=== Clé API ===
+Une **clé API** ou jeton API, est une **chaîne alphanumérique unique générée par le serveur** et affectée à un utilisateur. Pour obtenir une clé API unique, l'utilisateur se connecte généralement à un portail à l'aide de ses informations d'identification. Cette clé est généralement assignée une fois et ne sera pas régénérée. Toutes les requêtes d'API REST pour cet utilisateur doivent fournir la clé d'API assignée comme forme d'authentification.
+Tout comme avec les autres types d'authentification, les clés API ne sont sécurisées que lorsqu'elles sont utilisées avec HTTPS.
+Les clés API sont destinées à être un mécanisme d'authentification, mais sont généralement utilisées à mauvais escient comme mécanisme d'autorisation.
+Les deux types de clés API sont publiques et privées.
+  * Une clé d'API publique peut être partagée et permet à cet utilisateur d'accéder à un sous-ensemble de données et d'API.
+  * une clé privée ne doit pas être partagée, car elle est similaire à votre nom d'utilisateur et votre mot de passe.
+La plupart des clés d'API n'expirent pas, et à moins que la clé ne puisse être révoquée ou régénérée, si elle est distribuée ou compromise, toute personne disposant de cette clé peut accéder indéfiniment au système comme vous.
+<WRAP center round info>
+Une requête API REST peut fournir une clé API de différentes manières:
+<code>
+Query string: Recommandé uniquement pour les clés API publiques
+</code>
+  * Header: Utilise la clé Autorisation ou une clé personnalisée
+<code>
+Authorization: <API Key>
+ou
+Authorization: APIkey <API Key>
+ou
+APIkey: <API Key>
+</code>
+  * Body data: Utilise une clé unique comme identifiant
+<code>
+Content-Type: application/json
+</code>
+  * Cookie: Utilise une clé unique comme identifiant
+<code>
+Cookie: API_KEY=<API Key>
+</code>
+</WRAP>
 ==== Retour Activité A8 ====
   * [[glpi_gestionconfig_00|A8 - La gestion des configurations avec GLPI]]