Partager via

Exemple de procédure pas à pas d’inscription

  • Article

Cet article présente les étapes requises pour effectuer une inscription en 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 « VPN de carte à puce virtuelle » et l’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, notant qu’un seul élément de collecte de données intitulé « Raison de la demande » s’affiche. Le client note également que l’indicateur collectComments est défini sur false. Il n’invite donc pas l’utilisateur à en entrer.

  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 a correctement créé 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é d’é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 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 une si le modèle de profil est configuré pour les 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. 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 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 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 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 reconverti 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 note que l’utilisateur doit fournir l’épingle souhaitée en inspectant le champ UserPinOption dans la stratégie de carte à puce.

  22. Une fois que l’utilisateur a entré l’épingle souhaitée dans une boîte de dialogue, le client effectue une authentification de demande-réponse comme indiqué à l’étape 19, la seule différence étant que l’indicateur diversifié doit maintenant être défini sur 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é 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 la clé, etc. 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 é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, c’est-à-dire que 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é 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 demande comme terminée.

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

{
    "status":"Completed"
}