Genomgång av exempelregistrering

Den här artikeln visar de steg som krävs för att utföra en registrering med självbetjäning av virtuella smartkort. Den visar en automatiskt godkänd begäran med en PIN-kod som anges av användaren.

  1. Klienten autentiserar användaren och begär sedan en lista med profilmallar som den autentiserade användaren kan registrera sig för:

    GET /CertificateManagement/api/v1.0/profiletemplates.
    
  2. Klienten visar den resulterande listan för användaren. Användaren väljer en vSC-profilmall (virtuellt smartkort) med namnet "Virtual Smartcard VPN" och UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

  3. Klienten hämtar registreringsprincipen för den valda profilmallen med hjälp av UUID som returnerades i föregående steg:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
    
  4. Klienten analyserar fältet DataCollection i den returnerade principen och konstaterar att ett enda datainsamlingsobjekt med titeln "Begärandeorsak" visas. Klienten noterar också att flaggan collectComments är inställd på false, så användaren uppmanas inte att ange någon.

  5. När användaren har angett orsaken till att certifikaten krävs skapar klienten en begäran:

    POST /CertificateManagement/api/v1.0/requests
    
    {
        "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
        "type":"Enroll",
        "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
        "comment":""
    }
    
  6. Servern skapar begäran och returnerar URI:n för begäran till klienten: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

  7. Klienten hämtar begärandeobjektet genom att anropa den returnerade URI:n:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
  8. Klienten verifierar att tillståndsegenskapen i begäran är inställd på godkänd. Körningen av begäran kan påbörjas.

  9. Klienten undersöker begäran för att se om det finns ett smartkort som redan är associerat med begäran genom att analysera innehållet i parametern newsmartcarduuid .

  10. Eftersom den bara innehåller ett tomt GUID måste klienten antingen använda ett befintligt kort som inte redan används av MIM CM eller skapa ett om profilmallen konfigureras för virtuella smartkort.

  11. Eftersom det senare har angetts för klienten via den första frågan för registreringsbara profilmallar (steg 1) måste klienten nu skapa en virtuell smartkortsenhet.

  12. Klienten hämtar principen för smartkort från profilmallen. Den använder UUID för mallen som valdes i steg 3:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    
  13. Principen för smartkort innehåller standardadministratörsnyckeln för kortet i egenskapen DefaultAdminKeyHex . När du skapar smartkortet måste klienten ange den första administratörsnyckeln för smartkortet till den här nyckeln.

  14. När smartkortsenheten skapas måste klienten tilldela den till begäran:

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    
  15. Servern svarar på klienten med en URI till det nyligen skapade smartkortsobjektet: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

  16. Klienten hämtar smartkortsobjektet:

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    
  17. Genom att kontrollera värdet för flaggan diversifyadminkey i smartkortsprincipen som erhölls i steg 12 vet klienten att den måste diversifiera administratörsnyckeln.

  18. Klienten hämtar den föreslagna administratörsnyckeln:

    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. Klienten måste autentisera till kortet som administratör för att kunna ange administratörsnyckeln. För att göra detta begär klienten en autentiseringsuppgift från smartkortet och skickar den till servern:

    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
    

    Servern skickar utmaningssvaret i HTTP-svarstexten. Leta upp den hexadecimala utmaningssträngen, konvertera till base64 och skicka den som en parameter i URL:en. URL:en returnerar ett annat svar som måste konverteras tillbaka till hexadecimalt format.

  20. Servern skickar utmaningssvaret i HTTP-svarstexten och klienten använder det för att diversifiera administratörsnyckeln.

  21. Klienten noterar att användaren måste ange önskad PIN-kod genom att granska fältet UserPinOption i principen för smartkort.

  22. När användaren har angett önskad pin-kod i en dialogruta utför klienten en autentisering med utmaningssvar enligt beskrivningen i steg 19, där den enda skillnaden är att den diversifierade flaggan nu ska vara inställd på sant:

    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. Klienten använder svaret som togs emot från servern för att ange önskad pin-kod för användaren.

  24. Klienten är nu redo att generera certifikatbegäranden. Den frågar parametrarna för generering av profilmallcertifikat för att avgöra hur nycklar/begäranden ska genereras.

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
    
  25. Servern svarar med ett enda JSON-serialiserat CertificateRequestGenerationOptions-objekt . Objektet innehåller parametrar för nyckelns exportbarhet, eget certifikatnamn, hash-algoritm, nyckelalgoritm, nyckelstorlek och så vidare. Klienten använder dessa parametrar för att generera en certifikatbegäran.

  26. Den enskilda certifikatbegäran skickas till servern. Klienten kan dessutom ange ett PFX-lösenord som ska användas för att dekryptera alla PFX-blobar när certifikatmallen anger arkivering av certifikaten på certifikatutfärdare, dvs. ca:en genererar nyckelparet och skickar det sedan till klienten. Klienten kan också välja att lägga till några kommentarer.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    
  27. Efter några sekunder svarar servern med ett enda JSON-serialiserat Microsoft.Clm.Shared.Certificate-objekt . Genom att kontrollera isPkcs7-flaggan lär sig klienten att det här svaret inte är en PFX-blob. Klienten extraherar bloben genom att base64 avkoda pkcs7-strängen och installera den.

  28. Klienten markerar begäran som slutförd.

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