Partager via

Exemple de procédure pas à pas d’inscription

Cet article présente les étapes requises pour effectuer une inscription en libre-service de carte à puce virtuelle. Il affiche une demande approuvé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 profil auxquels l’utilisateur authentifié peut s’inscrire :

    GET /CertificateManagement/api/v1.0/profiletemplates.

  2. Le client affiche la liste obtenue à l’utilisateur. L’utilisateur sélectionne un modèle de profil vSC (carte à puce virtuelle) avec le nom « VPN de carte à puce virtuelle » 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 intitulé « Motif de la demande » s’affiche. Le client note également que l’indicateur collectComments a la valeur false. Il n’invite donc pas l’utilisateur à entrer.

  5. Une fois que l’utilisateur a entré la raison d’exiger les 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 requête et retourne l’URI de la requête au client : /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

  7. Le client récupère l’objet de requête en appelant l’URI retourné :

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5

  8. Le client vérifie que, dans la requête, l’état de la propriété est approuvé. L’exécution de la demande peut commencer.

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

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

  11. Étant donné que ce dernier a été indiqué au client par le biais de la requête initiale pour les modèles de profil pouvant être inscrits (étape 1), le client doit maintenant créer un appareil de carte à puce virtuelle.

  12. Le client récupère les règles de carte à puce à partir du modèle de profil. Il 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 la clé d’administration initiale de la carte à puce sur cette clé.

  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 pour 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 diversadminkey 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 un défi d’authentification à partir de la carte à puce et l’envoie 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 défi dans le corps de la réponse HTTP. Recherchez la chaîne de défi hexadécimale, convertissez en base64 et transmettez-la en tant que paramètre dans l’URL. L’URL retourne une autre réponse, qui doit être convertie au format hexadécimal.

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

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

  22. Une fois que l’utilisateur a entré le code PIN souhaité dans une boîte de dialogue, le client effectue une authentification de type challenge-response comme indiqué à l’étape 19, avec pour seule différence que le drapeau diversifié doit maintenant être réglé sur vrai :

    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 du serveur pour définir le code PIN 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 la façon dont les clés/demandes 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é JSON. L’objet inclut des paramètres pour l’exportation de la clé, le nom convivial du certificat, l’algorithme de hachage, l’algorithme de clé, la taille de clé, et ainsi de suite. Le client utilise ces paramètres pour générer une demande de certificat.

  26. La demande de certificat unique est envoyée au serveur. Le client peut également 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, puis 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 seul objet Microsoft.Clm.Shared.Certificate sérialisé au format 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 la chaîne pkcs7 en base64 et l’installe.

  28. Le client marque la requête comme terminée.

    PUT /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5

{
    "status":"Completed"
}
  • Last updated on