Beispielhafte Vorgehensweise für die Registrierung

In diesem Artikel werden die Schritte beschrieben, die erforderlich sind, um eine Self-Service-Registrierung für virtuelle Smartcards durchzuführen. Es zeigt eine automatisch genehmigte Anforderung mit einer vom Benutzer festgelegten PIN an.

1. Der Client authentifiziert den Benutzer und fordert dann eine Liste der Profilvorlagen an, für die sich der authentifizierte Benutzer registrieren kann:

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

2. Der Client zeigt dem Benutzer die resultierende Liste an. Der Benutzer wählt eine vSC-Profilvorlage (virtuelle Smartcard) mit dem Namen "Virtual Smartcard VPN" und UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1aus.

3. Der Client ruft die Registrierungsrichtlinie der ausgewählten Profilvorlage mithilfe der im vorherigen Schritt zurückgegebenen UUID ab:

   GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
   

4. Der Client analysiert das DataCollection-Feld in der zurückgegebenen Richtlinie, wobei angegeben wird, dass ein einzelnes Datensammlungselement mit dem Titel "Anforderungsgrund" angezeigt wird. Der Client weist außerdem darauf hin, dass das flag "collectComments " auf "false" festgelegt ist, sodass er den Benutzer nicht auffordert, einzugeben.

5. Nachdem der Benutzer den Grund für die Anforderung der Zertifikate eingegeben hat, erstellt der Client eine Anforderung:

   POST /CertificateManagement/api/v1.0/requests
   
   {
       "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
       "type":"Enroll",
       "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
       "comment":""
   }
   

6. Der Server erstellt die Anforderung erfolgreich und gibt den URI der Anforderung an den Client zurück: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

7. Der Client ruft das Anforderungsobjekt ab, indem der zurückgegebene URI aufgerufen wird:

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

8. Der Client überprüft, ob die Statuseigenschaft in der Anforderung auf "genehmigt" festgelegt ist. Die Anforderungsausführung kann beginnen.

9. Der Client untersucht die Anforderung, um festzustellen, ob der Anforderung bereits eine Smartcard zugeordnet ist, indem der Inhalt des newsmartcarduuid-Parameters analysiert wird.

10. Da er nur eine leere GUID enthält, muss der Client entweder eine vorhandene Karte verwenden, die nicht bereits von MIM CM verwendet wird, oder eine erstellen, wenn die Profilvorlage für virtuelle Smartcards konfiguriert ist.

11. Da letztere dem Client über die erste Abfrage für registrierte Profilvorlagen (Schritt 1) angegeben wurde, muss der Client nun ein virtuelles Smartcardgerät erstellen.

12. Der Client ruft die Smartcardrichtlinie aus der Profilvorlage ab. Es verwendet die UUID der Vorlage, die in Schritt 3 ausgewählt wurde:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    

13. Die Smartcardrichtlinie enthält den Standardadministratorschlüssel für die Karte in der DefaultAdminKeyHex -Eigenschaft. Beim Erstellen der Smartcard muss der Client den anfänglichen Administratorschlüssel der Smartcard auf diesen Schlüssel festlegen.

14. Beim Erstellen des Smartcardgeräts muss der Client es der Anforderung zuweisen:

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    

15. Der Server antwortet auf den Client mit einem URI auf das neu erstellte Smartcardobjekt: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

16. Der Client ruft das Smartcardobjekt ab:

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    

17. Durch Überprüfung des Werts des diversifyadminkey-Flags in der Smartcard-Richtlinie, die in Schritt 12 abgerufen wurde, weiß der Client, dass er den Administratorschlüssel diversifizieren muss.

18. Der Client ruft den vorgeschlagenen Administratorschlüssel ab:

    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. Der Client muss sich als Administrator bei der Karte authentifizieren, um den Administratorschlüssel festzulegen. Dazu fordert der Client eine Authentifizierungsabfrage von der Smartcard an und sendet sie an den Server:

    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
    

    Der Server sendet die Abfrageantwort im HTTP-Antworttext. Suchen Sie die hexadezimale Abfragezeichenfolge, konvertieren Sie sie in base64, und übergeben Sie sie als Parameter in der URL. Die URL gibt eine weitere Antwort zurück, die wieder in hexadezimales Format konvertiert werden muss.

20. Der Server sendet die Abfrageantwort im HTTP-Antworttext, und der Client verwendet sie, um den Administratorschlüssel zu diversifizieren.

21. Der Client stellt fest, dass der Benutzer seine gewünschte Pin bereitstellen muss, indem er das UserPinOption-Feld in der Smartcardrichtlinie prüft.

22. Nachdem der Benutzer seine gewünschte PIN in ein Dialogfeld eingegeben hat, führt der Client eine Abfrageantwortauthentifizierung aus, wie in Schritt neunzehn beschrieben, wobei der einzige Unterschied darin besteht, dass das diversifizierte Flag jetzt auf "true" festgelegt werden sollte.

    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. Der Client verwendet die vom Server empfangene Antwort, um die gewünschte Benutzer-PIN festzulegen.

24. Der Client ist jetzt bereit, Zertifikatanforderungen zu generieren. Es fragt die Parameter der Zertifikatgenerierung von Profilvorlagen ab, um zu bestimmen, wie die Schlüssel/Anforderungen generiert werden sollen.

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

25. Der Server antwortet mit einem einzelnen JSON-serialisierten CertificateRequestGenerationOptions -Objekt. Das Objekt enthält Parameter für die Exportierbarkeit des Schlüssels, den Friendly Name des Zertifikats, den Hashing-Algorithmus, den Schlüsselalgorithmus, die Schlüsselgröße usw. Der Client verwendet diese Parameter, um eine Zertifikatanforderung zu generieren.

26. Die einzelne Zertifikatanforderung wird an den Server übermittelt. Der Client könnte zusätzlich ein PFX-Kennwort angeben, das zum Entschlüsseln aller PFX-Blobs verwendet werden soll, wenn die Zertifikatvorlage die Archivierung der Zertifikate auf der Zertifizierungsstelle angibt, d. h. die Zertifizierungsstelle generiert das Schlüsselpaar und sendet es dann an den Client. Der Client kann auch einige Kommentare hinzufügen.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    

27. Nach ein paar Sekunden antwortet der Server mit einem einzelnen, JSON-serialisierten Microsoft.Clm.Shared.Certificate-Objekt . Durch Überprüfen des isPkcs7-Flags lernt der Client, dass diese Antwort kein PFX-BLOB ist. Der Client extrahiert das Blob durch base64-Decodieren der pkcs7-Zeichenfolge und installiert es.

28. Der Client markiert die Anforderung als abgeschlossen.

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