API OpenFlyers

Révision de 14 novembre 2023 à 16:49 par Claratte (discuter | contributions) (→‎Client OAuth2)

Aller à : navigation, rechercher

Présentation

L'objet de cette page est de décrire l'API OpenFlyers.

Description de l'API

OpenFlyers possède une API basée sur OAuth2 qui permet à des serveurs extérieurs, dûment enregistrés, de mettre en œuvre un processus d'authentification unique (SSO) et/ou de récupération des résultats des requêtes SQL de la bibliothèque des rapports ou des rapports personnalisés sous la forme de fichiers CSV.

OAuth2 propose plusieurs mécanismes pour permettre l'authentification. Un mécanisme d'authentification détermine la séquence exacte des étapes impliquées dans le processus d'authentification d'OAuth2. OpenFlyers met à disposition deux mécanismes d'authentification :

  • Authorization Code basé sur la méthode d'authentification par code d'autorisation et qui correspond au mécanisme associé à l'authentification unique (SSO),
  • Client Credentials basé sur la méthode d'authentification avec les identifiants clients et qui est utilisé dans un contexte d'automatisme sans autorisation de l'utilisateur au préalable.

Dans les chapitres qui suivent, le terme ressource fait référence à la définition OAuth2. Une ressource dans OAuth2 est un élément qui peut être :

  • une ou des données comme des photos, des documents, des contacts ou des informations personnelles,
  • un ou plusieurs services comme des transferts de fonds, la récupération de rapports ou l'ajout d'articles sur un blog,
  • toute ressource nécessitant un accès restreint.

OpenFlyers définit plusieurs types de ressources :

OAuth2 dispose de scopes. Un scope est un privilège définit de manière explicite permettant l'accès à une ressource protégée. OpenFlyers met à disposition une liste de scopes utilisables à travers l'API.

Deux protocoles de sécurité sont présents dans l'API OpenFlyers :

  • mTLS : il permet d'authentifier le client avec un certificat TLS, en plus d'authentifier le serveur avec un certificat. Ce protocole permet d'éviter les usurpations d'identité.
  • HTTP-Signature : il permet de signer les en-têtes et le corps (lorsqu'il y en a un) des messages échangés afin d'en garantir leur intégrité.
Premiers pas - Client de démonstration

Un client de démonstration est disponible pour comprendre les mécanismes décrits ci-dessous.

L'utilisation de ce client de démonstration est décrite dans le chapitre Client de démonstration de cette page.

Le client de démonstration est lui-même accessible à cette adresse : https://openflyers.com/oauth2-demo/index.php

Le code source du client de démonstration est mis à disposition par OpenFlyers à cette adresse : https://openflyers.com/oauth2-demo/oauth2-demo-src.zip

L'utilisation du code source est décrite dans le chapitre Configurer le client à partir du code source.

Authentification TLS Mutuelle (mTLS)

En général dans une communication TLS, seul le serveur a l'obligation de fournir un certificat. Il est également possible pour le client de fournir un certificat. Ce principe s'appelle l'authentification mutuelle et est mise en place avec Mutual TLS (ou mTLS).

OpenFlyers associe un certificat pour l'authentification mutuelle unique à chaque client OAuth2.

Envoyer un certificat client

Côté client, le code suivant peut être utilisé pour fournir à cURL le certificat et la clé correspondante ainsi que le certificat du CA d'OpenFlyers à utiliser pour la connexion : 

curl_setopt_array($request, [
    CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2,
    CURLOPT_CAINFO     => $caCertificatePath,
    CURLOPT_SSLCERT    => $certificatePath,
    CURLOPT_SSLKEY     => $keyPath
]);

À noter : le certificat du CA d'OpenFlyers est nécessaire pour assurer la validité des certificats utilisés.

HTTP Signature

HTTP Signature utilise le principe de la signature numérique pour garantir l'authenticité et l'intégrité du message HTTP.

La signature est générée à l'aide d'une clé privée et vérifiée à l'aide de la clé publique correspondante ou d'un certificat contenant cette clé publique.

HTTP Signature utilise deux en-têtes HTTP :

  • Signature : contient la signature et ses métadonnées.
  • Digest : contient le corps du message haché.

Digest

Le digest est calculé comme ceci : digest = base64encode(sha256(corps du message))

Et l'en-tête est structuré de la manière suivante : Digest: SHA-256=<digest>

Un autre algorithme de hachage peut être utilisé, SHA-256 reste cependant le plus répendu.

Exemple en php
$digestHeader = 'Digest: SHA-256=' . base64_encode(hash('sha256', $postData, true));

Signature

L'en-tête HTTP de signature est structuré de la manière suivante : Signature: keyId="<keyId>",algorithm="<algo>",headers="<signed_headers>",signature="<signature>"

Le champ keyId correspond à un identifiant permettant l'identification de la clé utilisée pour vérifier la signature. Pour l'API d'OpenFlyers, sa valeur correspond à l'empreinte SHA-1 du certificat au format PEM à utiliser pour vérifier la signature.

L'algorithme algo correspond à celui utilisé pour générer la signature, exemple : rsa-sha256.

La valeur de signed_headers correspond à la liste des en-têtes inclus dans la signature séparés d'un espace. Exemple : date digest (request-target)

Pour générer la signature, une chaîne de caractères appelée signing string contenant les en-têtes au format lowercase_header_name: value séparés par une nouvelle ligne au format LF (\n) est d'abord générée. Exemple avec les en-têtes "date" et "(request-target)" : 

(request-target): post /some/uri\ndate: Tue, 07 Jun 2014 20:51:35 GMT

La signature est ensuite générée comme ceci : base64encode(algo(signing string))

Exemple en php
function generateSignatureHeader(array $headersToSign, string $certificateFingerprint, string $privateKey): string
{
    // generating the signing string and header list
    $headers         = '';
    $signatureString = '';
    foreach ($headersToSign as $key => $value) {
        $normalizedHeaderKey = trim(strtolower($key));
        $headers             .= $normalizedHeaderKey . ' ';
        $signatureString     .= $normalizedHeaderKey . ': ' . trim($value) . "\n";
    }
 
    // trim extra whitespace
    $headers         = trim($headers);
    $signatureString = trim($signatureString);
 
    // signing the signing string
    $signature = '';
    openssl_sign($signatureString, $signature, $privateKey, 'RSA-SHA256');
    $signature = base64_encode($signature);
 
    // compiling the header line
    return "Signature: keyId=\"$certificateFingerprint\",algorithm=\"rsa-sha256\",headers=\"$headers\",signature=\"$signature\"";
}

Les variables $certificateFingerprint et $privateKey correspondent respectivement à une empreinte SHA-1 de certificat et à une clé privée, tous deux au format PEM.

La variable $headersToSign est un tableau formaté de la manière suivante : 

[
    $headerName => $headerValue,
    ...
]

À noter : les en-têtes sont à signer côté client avec le certificat de signature signé par le CA d'OpenFlyers et dédié au client ainsi que la clé privée associée. Le certificat de signature dédié au client est téléchargeable depuis l'interface de gestion des clients OAuth2. Les en-têtes de la réponse du serveur quant à elles doivent être vérifiées avec le certificat de signature HTTP du serveur, téléchargeable aussi depuis l'interface de configuration des clients OAuth2.

Procédures

Configurer le client à partir du code source

Prérequis

Un client de démonstration est disponible pour le logiciel OpenFlyers à cette adresse : https://openflyers.com/oauth2-demo/index.php

Télécharger Le code source du client de démonstration 

Le code source est mis à disposition par OpenFlyers à cette adresse : https://openflyers.com/oauth2-demo/oauth2-demo-src.zip

Le code source est structuré de la manière suivante :

Oauth2 src demo folder.png

  • Le dossier css contient tout le matériel nécessaire à la stylisation de la page web.
  • Le dossier img contient les images affichées sur la page web.
  • Le dossier ssl est le dossier contenant tous les certificats et les clé privées associées à chaque client. Il doit respecter une structure particulière décrite ci-dessous.
  • Le fichier ClientDemo.php contient la classe ClientDemo. Cette classe contient toutes les méthodes nécessaires au fonctionnement du client de démonstration OAuth2.
  • Le fichier index.php est le fichier à appeler depuis le navigateur. Ce fichier correspond au fichier qui gère les appels à la classe ClientDemo et exécute les méthodes dans l'ordre.

Le dossier ssl doit respecter la structure suivante :

Oauth2 demo tree.png

Générer les certificats 

Après la génération des certificats, les clés privées 'auth.key' et 'sign.key' remplacent celles présentes dans les dossiers 'ssl/AuthCodeDemo' et 'ssl/ClientCredDemo'.

Enregistrer les clients 
  • Deux clients doivent être créés :
    • Le premier pour le mécanisme d'autorisation Authorization Code,
    • Le second pour le mécanisme d'autorisation Client Credentials.

Oauth2 demo manage.png

  • Télécharger le certificat du CA OpenFlyers en cliquant sur le bouton Télécharger le certificat CA de la page de gestion. Télécharger aussi le certificat de signature du serveur en cliquant sur le bouton Télécharger le certificat de signature du serveur de la page de gestion. Placer les deux certificats téléchargés à la racine du dossier ssl.
  • Télécharger les deux certificats Certificat d'authentification et Certificat de signature du client Authorization Code et les placer dans le répertoire ssl/AuthCodeDemo.
  • Modifier le fichier ssl/AuthCodeDemo/config.authcode.json en le remplissant de la manière suivante.
{
  "client_id": "XXXXXXXXXXXXXXXX",
  "client_secret": "XXXXXXXXXXXXXXXX",
  "authorize_uri": "https://openflyers.com/mastructure/oauth/authorize.php",
  "token_uri": "https://openflyers.com/mastructure/oauth/access_token.php",
  "resource_uri": "https://openflyers.com/mastructure/oauth/resources.php",
  "revoke_uri": "https://openflyers.com/mastructure/oauth/revoke.php",
  "auth_cert": "path_to_client/ssl/AuthCodeDemo/auth_cert.crt",
  "auth_key": "path_to_client/ssl/AuthCodeDemo/auth.key",
  "sign_cert": "path_to_client/ssl/AuthCodeDemo/sign_cert.crt",
  "sign_key": "path_to_client/ssl/AuthCodeDemo/sign.key",
  "auth_cacert": "path_to_client/ssl/ca.crt",
  "sign_cert_server": "path_to_client/ssl/sign_cert_server.crt"
}
  • Remplacer les XXXXXXXXXXXXXXXX des champs client_id et client_secret par les valeurs obtenues lors de l'enregistrement du client.
  • Remplacer mastructure par le nom de la structure sur laquelle la démo est testée.
  • Remplacer path_to_client/ par le chemin d'accès vers le dossier qui contient le code source du client de démonstration.
    • Exemple sur windows: C:/wamp64/www/4.0/oauth-demo/.
    • Exemple sur un serveur Linux debian: ./.


  • Télécharger les deux certificats Certificat d'authentification et Certificat de signature du client Client Credentials et les placer dans le répertoire ssl/ClientCredDemo.
  • Modifier le fichier ssl/ClientCredDemo/config.clientcred.json en le remplissant de la manière suivante.
{
  "client_id": "XXXXXXXXXXXXXXXX",
  "client_secret": "XXXXXXXXXXXXXXXX",
  "token_uri": "https://openflyers.com/mastructure/oauth/access_token.php",
  "resource_uri": "https://openflyers.com/mastructure/oauth/resources.php",
  "revoke_uri": "https://openflyers.com/mastructure/oauth/revoke.php",
  "auth_cert": "path_to_client/ssl/ClientCredDemo/auth_cert.crt",
  "auth_key": "path_to_client/ssl/ClientCredDemo/auth.key",
  "sign_cert": "path_to_client/ssl/ClientCredDemo/sign_cert.crt",
  "sign_key": "path_to_client/ssl/ClientCredDemo/sign.key",
  "auth_cacert": "path_to_client/ssl/ca.crt",
  "sign_cert_server": "path_to_client/ssl/sign_cert_server.crt"
}
  • Remplacer les XXXXXXXXXXXXXXXX des champs client_id et client_secret par les valeurs obtenues lors de l'enregistrement du client.
  • Remplacer mastructure par le nom de la structure sur laquelle la démo est testée.
  • Remplacer path_to_client/ par le chemin d'accès vers le dossier qui contient le code source du client de démonstration.
    • Exemple sur windows: C:/wamp64/www/4.0/oauth-demo/.
    • Exemple sur un serveur Linux debian: ./.



NB: Le certificat de signature du serveur est unique à chaque plateforme et serveur. Ainsi, si le serveur ou la plateforme est modifié, le certificat doit être renouvelé.

Enregistrer un client

Pour utiliser l'API OAuth2, il faut enregistrer un client OAuth2 auprès d'OpenFlyers. Pour ceci, suivre les étapes suivantes :


Pour le mécanisme d'authentification Client Credentials
  • Créer un nouveau profil. Ce profil doit permettre de gérer les droits du client OAuth2. Choisir un nom explicite, par exemple "Client OAuth rapports".
  • Sélectionner les droits à assigner à ce profil. Ces droits limitent les données auxquelles le client OAuth2 a accès.
    • Sélectionner les droits relatifs à l'enregistrement de clients OAuth2 dans l'onglet Admin (colonne Associé aux clients OAuth2).
    • Sélectionner les rapports accessibles par le profil précédemment créé.
  • Créer un nouvel utilisateur à partir du panneau de gestion. Cet utilisateur est virtuel et représente le serveur sur lequel fonctionne le client OAuth2.
    • Des identifiant et nom explicites sont recommandés (exemple : "serv1_oauth_client")
    • Attention : tout utilisateur désactivé et associé à un client OAuth2 rend le client inactif, il faut donc changer l'utilisateur associé au client pour réactiver le client.


Pour le mécanisme d'authentification Authorization Code
  • Aller dans Admin > Utilisateurs > Profils
  • Dans l'onglet Généralités, cocher la case relative à la colonne Connexion depuis l'extérieur (OAuth2) pour le profil souhaité.


Créer un nouveau client OAuth2
  • Aller dans Admin > Imports > API OAuth2 > Paramètres

Oauth2 manage.png

  • Cliquer sur le bouton Ajouter + ou Ajouter un client

Oauth2 client creation.png

  • Choisir un nom pour le client.
  • Sélectionner le mécanisme d'autorisation utilisé par le client :
    • Authorization Code: permet d'utiliser OAuth2 comme solution SSO ou accéder à des données utilisateurs. Cette méthode peut être couplée avec le mécanisme de mémorisation de connexion (Refresh Token).
    • Client Credentials: permet d'utiliser OAuth2 dans un contexte d'automatisme.
  • Saisir l'URI de redirection vers le client pour le mécanisme Authorization Code.
  • Sélectionner l'utilisateur virtuel créé précédemment pour le mécanisme Client Credentials.
  • Générer deux CSR afin d'obtenir deux certificats signés et les saisir :
    • Certificate Signing Request pour le certificat d'authentification est utilisé pour l'authentification mutuelle avec mTLS (auth_cert.csr.pem).
    • Certificate Signing Request pour le certificat de signature est utilisé pour la signature des en-têtes HTTP (sign_cert.csr.pem).
  • Cliquer sur Enregistrer.


Sauvegarder le couple ID/passphrase

Un couple ID/passphrase (client_id/client_secret) est généré. Ces deux clées ne sont communiquées qu'une seule fois. Elle doivent être stockées en toute sécurité et gardées confidentielles. Oauth2 client created.png


Remarques
  • Les certificats du CA d'OpenFlyers et de signature HTTP du serveur sont nécessaires. Ils sont téléchargeables depuis l'interface de configuration des clients OAuth2.
  • Dans certains cas d'utilisation, il peut être nécessaire d'ajouter le certificat du CA d'OpenFlyers au Trust Store du système. Si cette étape n'est pas réalisée, les certificats peuvent être considérés comme invalides et peuvent ne pas être utilisables.
  • Pour ajouter le certificat CA au Trust Store du système, suivre les étapes suivantes:
    • Sous Linux, copier le certificat CA d'OpenFlyers dans le dossier /usr/local/share/ca-certificates et exécuter la commande sudo update-ca-certificates
    • Sous Windows,
      • Double-cliquer sur le certificat CA d'OpenFlyers téléchargé depuis l'interface d'enregistrement des clients OAuth2
      • Cliquer sur Installer un certificat...
      • Choisir l'emplacement de stockage (utilisateur ou ordinateur) et cliquer sur Suivant puis Suivant et enfin Terminer

Générer des certificats

L'API OAuth2 implémente HTTP Signature et l'authentification TLS mutuelle. Ces mécanismes utilisent chacun une paire certificat/clé privée différente.

Pour obtenir ces certificats, il faut d'abord générer des Certificate Signing Request (CSR).

La procédure est la suivante :

Fichier de configuration OpenSSL - sign_cert.conf
[req]
default_bits       = 4096                     # taille par défaut des nouvelles clés, peut être surchargé dans la commande
encrypt_key        = no                       # chiffrer la clé générée
distinguished_name = req_distinguished_name   # pointe vers la catégorie spécifiée pour le Distinguished Name
x509_extensions    = v3_req                   # pointe vers la catégorie spécifiée pour les extensions x509
prompt             = no

[req_distinguished_name]
C                  =                          # code à deux chiffres du pays (ex: FR)
ST                 =                          # région/état (ex: Gironde)
L                  =                          # ville (ex: Bordeaux)
O                  =                          # organisation (ex: OpenFlyers)
OU                 =                          # unité organisationelle (ex: IT)
CN                 =                          # nom de domaine (ex: openflyers.com)

[v3_req]
keyUsage           = digitalSignature         # pour quelles opérations la clé peut-elle être utilisée
Fichier de configuration OpenSSL - auth_cert.conf
[req]
default_bits       = 4096                     # taille par défaut des nouvelles clés, peut être surchargé dans la commande
encrypt_key        = no                       # chiffrer la clé générée
distinguished_name = req_distinguished_name   # pointe vers la catégorie spécifiée pour le Distinguished Name
x509_extensions    = v3_req                   # pointe vers la catégorie spécifiée pour les extensions x509
prompt             = no

[req_distinguished_name]
C                  =                          # code à deux chiffres du pays (ex: FR)
ST                 =                          # région/état (ex: Gironde)
L                  =                          # ville (ex: Bordeaux)
O                  =                          # organisation (ex: OpenFlyers)
OU                 =                          # unité organisationelle (ex: IT)
CN                 =                          # nom de domaine (ex: openflyers.com)

[v3_req]
extendedKeyUsage   = clientAuth               # pour quelles opérations la clé peut-elle être utilisée


Exécuter les commandes suivantes : 

  • openssl req -sha256 -newkey rsa -keyout sign.key -out sign_cert.csr.pem -outform PEM -config sign_cert.conf
  • openssl req -sha256 -newkey rsa -keyout auth.key -out auth_cert.csr.pem -outform PEM -config auth_cert.conf

Ces commandes prennent chacune en entrée le fichier de configuration et génèrent une clé privée et un Certificate Signing Request.

Une fois ces CSR obtenus :

  • Les renseigner dans les champs prévus à cet effet lors de la création d'un client et télécharger les certificats signés depuis l'interface une fois le client créé.
  • Garder la clé privée confidentielle. Une fuite poserait un risque de sécurité. Elle va de paire avec le certificat distribué par l'autorité de certification OpenFlyers.

Mettre en place une connexion à l'API OpenFlyers sur un serveur mutualisé

Note

La procédure ci-après est destinée à une mise en place lorsqu'il n'y a pas d'accès SSH en ligne de commande mais uniquement un accès FTP. Dans ce cas, la création des clés privées et publics est effectuée "en local". Dans la procédure suivante elle est effectuée depuis un PC sous Windows.

Prérequis
Procédure

Utiliser le client

Prérequis

Un client de démonstration est disponible pour le logiciel OpenFlyers à cette adresse : https://openflyers.com/oauth2-demo/index.php

Le client de démonstration se présente de la manière suivante.

Oauth2 client demo.png

La démonstration est composée de deux colonnes. La première, nommée Authorization Code correspond au mécanisme d'autorisation du même nom. Elle dispose d'un bouton permettant de se connecter ainsi que d'une section indiquant les informations relatives à l'état de la connexion. La seconde colonne, nommée Client Credentials correspond elle aussi au mécanisme d'autorisation du même nom. Comme pour la première colonne, les éléments qui y sont présentés sont identiques. La différence étant que le bouton de connexion n'a pas le même effet étant donné que ces deux mécanismes sont différents. Chaque mécanisme est indépendant et il est possible de se connecter à un des deux mécanismes sans se connecter à l'autre ou se connecter aux deux en même temps.

Le mécanisme Authorization Code
  • Cliquer sur le bouton Se connecter (ce qui redirige le navigateur vers la page de connexion du logiciel OpenFlyers).
  • Renseigner les identifiants de l'administrateur pour s'y connecter.
  • Nom d'utilisateur : admini.
  • Mot de passe : azerty.

Une fois les informations saisies, la page suivante est affichée.

Oauth authorize demo.png

  • Cliquer sur le bouton Autoriser l'application pour autoriser la connexion (ce qui se redirige le navigateur vers la page du client de démonstration OAuth2).

La première colonne doit afficher l'état de connexion Connecté ainsi qu'un nouveau bouton Récupèrer les informations utilisateurs qui permet de récupérer les informations de l'utilisateur connecté.

Le mécanisme Client Credentials
  • Cliquer sur le bouton de connexion Se connecter: contrairement à celui du mécanisme Authorization Code, ne redirige pas le navigateur vers la page de connexion du logiciel OpenFlyers. Le bouton de connexion utilise les identifiants du client, ici le couple clé privée/clé publique, pour initier la connexion avec le serveur d'autorisation et obtenir un jeton d'accès.

Une fois la connexion établie, la seconde colonne doit afficher l'état de connexion Connecté ainsi qu'un menu déroulant Rapport à récupèrer et un nouveau bouton Récupèrer le rapport qui permet de récupérer les rapports génériques et personnalisés.


Le client, une fois connecté sur les deux mécanismes, se présente de la manière suivante.

Oauth2 connected demo.png

Troubleshooting

Erreur "File not found."

Cette erreur se produit lorsque l'URI utilisé n'existe pas sur le serveur OpenFlyers. Vérifier les URIs mis en place dans les fichiers de configuration et essayer de nouveau.