Expérience dans l'utilisation de la technologie Rutoken pour enregistrer et autoriser les utilisateurs dans le système (partie 3)

Bonne journée!

Dans la partie précédente Nous avons créé avec succès notre propre centre de certification. Comment peut-il être utile à nos fins ?

En utilisant une autorité de certification locale, nous pouvons émettre des certificats et également vérifier les signatures sur ces certificats.

Lors de la délivrance d'un certificat à un utilisateur, l'autorité de certification utilise une demande de certificat spéciale Pkcs#10, qui a le format de fichier « .csr ». Cette requête contient une séquence codée que l'autorité de certification sait analyser correctement. La requête contient à la fois la clé publique de l'utilisateur et les données permettant de créer un certificat (un tableau associatif avec des données sur l'utilisateur).

Nous verrons comment recevoir une demande de certificat dans le prochain article, et dans cet article je souhaite donner les principales commandes de l'autorité de certification qui nous aideront à accomplir notre tâche côté backend.

Nous devons donc d’abord créer un certificat. Pour ce faire, nous utilisons la commande :

openssl ca -batch -in user.csr -out user.crt

ca est la commande openSSL relative à l'autorité de certification,
-batch - annule les demandes de confirmation lors de la génération d'un certificat.
user.csr — demande de création d'un certificat (fichier au format .csr).
user.crt - certificat (résultat de la commande).

Pour que cette commande fonctionne, l'autorité de certification doit être configurée exactement comme décrit dans la partie précédente de l'article. Dans le cas contraire, vous devrez en outre préciser l'emplacement du certificat racine de l'autorité de certification.

Commande de vérification du certificat :

openssl cms -verify -in authenticate.cms -inform PEM -CAfile /Users/……/demoCA/ca.crt -out data.file

cms est une commande openSSL utilisée pour signer, vérifier, chiffrer des données et d'autres opérations cryptographiques à l'aide d'openSSL.

-verify - dans ce cas, nous vérifions le certificat.

Authenticate.cms - un fichier contenant des données signées avec le certificat émis par la commande précédente.

-inform PEM - Le format PEM est utilisé.

-CAfile /Users/……/demoCA/ca.crt - chemin d'accès au certificat racine. (sans cela, la commande n'a pas fonctionné pour moi, bien que les chemins vers ca.crt aient été écrits dans le fichier openssl.cfg)

-out data.file — J'envoie les données décryptées dans le fichier data.file.

L’algorithme d’utilisation d’une autorité de certification côté backend est le suivant :

• Enregistrement de l'utilisateur:
  1. Nous recevons une demande pour créer un certificat et l'enregistrer dans le fichier user.csr.
  2. Nous enregistrons la première commande de cet article dans un fichier avec l'extension .bat ou .cmd. Nous exécutons ce fichier à partir du code, après avoir préalablement enregistré la demande de création d'un certificat dans le fichier user.csr. Nous recevons un fichier avec le certificat user.crt.
  3. Nous lisons le fichier user.crt et l'envoyons au client.

• Autorisation de l'utilisateur :
  1. Nous recevons les données signées du client et les enregistrons dans le fichier Authenticate.cms.
  2. Enregistrez la deuxième commande de cet article dans un fichier avec l'extension .bat ou .cmd. Nous exécutons ce fichier à partir du code, après avoir préalablement enregistré les données signées du serveur dans Authenticate.cms. Nous recevons un fichier avec des données décryptées data.file.
  3. Nous lisons data.file et vérifions la validité de ces données. Ce qu'il faut vérifier exactement est décrit dans le premier article. Si les données sont valides, l'autorisation de l'utilisateur est considérée comme réussie.

Pour implémenter ces algorithmes, vous pouvez utiliser n'importe quel langage de programmation utilisé pour écrire le backend.

Dans le prochain article, nous verrons comment travailler avec le plugin Retoken.

Je vous remercie!

Source: habr.com