Exemplarische Vorgehensweise für die Registrierung

In diesem Artikel werden die schritte erläutert, die zum Durchführen einer Self-Service-Registrierung einer virtuellen Smartcard erforderlich sind. Es zeigt eine automatisch genehmigte Anforderung mit einer vom Benutzer festgelegten PIN.

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 Ergebnisliste an. Der Benutzer wählt eine vSC-Profilvorlage (virtuelle Smartcard) mit dem Namen "Virtual Smartcard VPN" und der UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1aus.

3. Der Client ruft die Registrierungsrichtlinie der ausgewählten Profilvorlage ab, indem er die UUID verwendet, die im vorherigen Schritt zurückgegeben wurde:

   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 und stellt fest, dass ein einzelnes Datensammlungselement mit dem Titel "Anforderungsgrund" angezeigt wird. Der Client stellt auch fest, dass das CollectComments-Flag auf false festgelegt ist, sodass der Benutzer nicht zur Eingabe eines aufgefordert wird.

5. Nachdem der Benutzer den Grund für das Anfordern 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 er den zurückgegebenen URI aufruft:

   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 er den Inhalt des newsmartcarduuid-Parameters analysiert.

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 karte erstellen, wenn die Profilvorlage für virtuelle Smartcards konfiguriert wird.

11. Da dem Client über die ursprüngliche Abfrage für registrierbare Profilvorlagen (Schritt 1) Letzteres angegeben wurde, muss der Client nun ein virtuelles Smartcard-Gerä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 . Wenn der Client die Smartcard erstellt, muss er den anfänglichen Administratorschlüssel der Smartcard auf diesen Schlüssel festlegen.

14. Beim Erstellen des Smartcard-Geräts muss der Client den Schlüssel 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 Smartcard-Objekt ab:

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

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

18. Der Client Ruft den vorgeschlagene 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 bei der Karte als Administrator authentifizieren, um den Administratorschlüssel festzulegen. Zu diesem Zweck fordert der Client eine Authentifizierungsaufforderung von der Smartcard an und sendet diese Aufforderung 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 Aufforderungsantwort im HTTP-Antworttext. Konvertieren Sie die hexadezimale Aufforderungszeichenfolge in base64, und übergeben Sie sie in der URL als Parameter. Die URL gibt eine weitere Antwort zurück, die zurück in das Hexadezimalformat konvertiert werden muss.

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

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

22. Nachdem der Benutzer seine gewünschte Pin in ein Dialogfeld eingegeben hat, führt der Client eine Challenge-Antwort-Authentifizierung aus, wie in Schritt 19 beschrieben, mit dem einzigen Unterschied, 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 Antwort, die er vom Server empfangen hat, um die gewünschte Benutzer-PIN festzulegen.

24. Der Client kann nun Zertifikatanforderungen generieren. Er fragt die Parameter für die Zertifikatgenerierung aus der Profilvorlage 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 Anzeigenamen des Zertifikats, den Hashalgorithmus, 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 gesendet. 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. Das heißt, die Zertifizierungsstelle generiert das Schlüsselpaar und sendet es dann an den Client. Der Client könnte auch einige Kommentare hinzufügen.

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

27. Nach einigen Sekunden antwortet der Server mit einem einzelnen, JSON-serialisierten Microsoft.Clm.Shared.Certificate-Objekt . Durch Überprüfen des isPkcs7-Flags erkennt der Client, dass es sich bei dieser Antwort um kein PFX-Blob handelt. Der Client extrahiert das Blob durch base64-Decodierung der pkcs7-Zeichenfolge und installiert es.

28. Der Client kennzeichnet die Anforderung als abgeschlossen.

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