Exemple de procédure d’inscription

Cet article présente les étapes requises pour effectuer une inscription libre-service de carte à puce virtuelle. Elle illustre une demande acceptée automatiquement avec un code confidentiel défini par l'utilisateur.

  1. Le client authentifie l'utilisateur, puis demande une liste de modèles de profils pour lesquels l'utilisateur authentifié peut s'inscrire :

    GET /CertificateManagement/api/v1.0/profiletemplates.
    
  2. Le client présente la liste résultante à l'utilisateur. L’utilisateur sélectionne un modèle de profil vSC (carte à puce virtuelle) avec le nom « Virtual Smartcard VPN » et UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1 .

  3. Le client récupère la stratégie d'inscription du modèle de profil sélectionné à l'aide de l'UUID retourné à l'étape précédente :

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
    
  4. Le client analyse le champ DataCollection dans la stratégie retournée, en notant qu’un seul élément de collecte de données nommé « Request Reason » s’affiche. Le client note également que l’indicateur collectComments est défini sur false, de sorte qu’il n’invite pas l’utilisateur à entrer des entrées.

  5. Une fois que l'utilisateur a entré le motif de la demande de certificats, le client crée une demande :

    POST /CertificateManagement/api/v1.0/requests
    
    {
        "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
        "type":"Enroll",
        "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
        "comment":""
    }
    
  6. Le serveur crée la demande et retourne l’URI de la demande au client : /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5 .

  7. Le client récupère l'objet de demande en appelant l'URI retourné :

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
  8. Le client vérifie que la propriété État dans la demande est définie sur approuvé. L'exécution de la demande peut commencer.

  9. Le client examine la demande pour voir si une carte à puce est déjà associée à la demande en analysant le contenu du paramètre newsmartcarduuid .

  10. étant donné qu’il ne contient qu’un GUID vide, le client doit soit utiliser une carte existante qui n’est pas déjà utilisée par MIM CM, soit en créer une si le modèle de profil est configuré pour des cartes à puce virtuelles.

  11. Comme ce dernier cas de figure a été indiqué au client via la requête initiale pour les modèles de profils pouvant être inscrits (étape 1), le client doit maintenant créer un appareil de carte à puce virtuelle.

  12. Le client récupère la stratégie de carte à puce à partir du modèle de profil. Elle utilise l’UUID du modèle sélectionné à l’étape 3 :

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    
  13. La stratégie de carte à puce contient la clé d’administration par défaut de la carte dans la propriété DefaultAdminKeyHex . Lors de la création de la carte à puce, le client doit définir cette clé comme clé d'administration initiale de la carte à puce.

  14. Lors de la création de l’appareil de carte à puce, le client doit l'affecter à la demande :

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    
  15. Le serveur répond au client avec un URI vers l’objet de carte à puce nouvellement créé : api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644 .

  16. Le client récupère l'objet de carte à puce :

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    
  17. En vérifiant la valeur de l’indicateur diversifyadminkey dans la stratégie de carte à puce obtenue à l’étape 12, le client sait qu’il doit diversifier la clé d’administration.

  18. Le client récupère la clé d'administration proposée :

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/diversifiedkey?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9
    
  19. Le client doit s'authentifier auprès de la carte en tant qu'administrateur pour définir la clé d'administration. Pour ce faire, le client demande une stimulation d'authentification à la carte à puce et la soumet au serveur :

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=false
    

    Le serveur envoie la réponse de stimulation dans le corps de la réponse HTTP. Recherchez la chaîne de stimulation hexadécimale, convertissez-la en base64 et transmettez-la en tant que paramètre dans l’URL. L’URL retourne une autre réponse, qui doit être reconvertie au format hexadécimal.

  20. Le serveur envoie la réponse de stimulation dans le corps de réponse HTTP et le client l'utilise pour diversifier la clé d'administration.

  21. Le client remarque que l’utilisateur doit fournir son code confidentiel souhaité en inspectant le champ UserPinOption dans la stratégie de carte à puce.

  22. Une fois que l’utilisateur a entré son code confidentiel dans une boîte de dialogue, le client effectue une authentification par stimulation-réponse comme indiqué à l’étape 19, la seule différence étant que l’indicateur diversifiéd doit maintenant avoir la valeur true :

    GET /CertificateManagement/api/v1.0/ requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=true
    
  23. Le client utilise la réponse reçue à partir du serveur pour définir le code confidentiel utilisateur souhaité.

  24. Le client est maintenant prêt à générer des demandes de certificat. Il interroge les paramètres de génération de certificat de modèle de profil pour déterminer comment les demandes/clés doivent être générées.

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
    
  25. Le serveur répond avec un seul objet CertificateRequestGenerationOptions SÉRIALISÉ en JSON. L’objet comprend des paramètres pour l’exportabilité de la clé, le nom convivial du certificat, l’algorithme de hachage, l’algorithme de clé, la taille de la clé, et ainsi de suite. Le client utilise ces paramètres pour générer une demande de certificat.

  26. La demande de certificat est soumise au serveur. Le client peut en outre spécifier un mot de passe PFX qui doit être utilisé pour déchiffrer les objets BLOB PFX lorsque le modèle de certificat spécifie l’archivage des certificats sur l’autorité de certification, autrement dit, l’autorité de certification génère la paire de clés et l’envoie au client. Le client peut également choisir d'ajouter des commentaires.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    
  27. Après quelques secondes, le serveur répond avec un objet Microsoft. CLM. Shared. Certificate unique SÉRIALISÉ en JSON. En vérifiant l’indicateur isPkcs7 , le client apprend que cette réponse n’est pas un objet BLOB PFX. Le client extrait l’objet BLOB en décodant en base64 la chaîne PKCS7 et l’installe.

  28. Le client marque la demande comme terminée.

    PUT /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
    {
        "status":"Completed"
    }