Przewodnik po przykładowej rejestracji

W tym artykule przedstawiono kroki wymagane do przeprowadzenia rejestracji samoobsługowej wirtualnej karty inteligentnej. Wyświetla automatycznie zatwierdzone żądanie z ustawionym przez użytkownika kodem PIN.

  1. Klient uwierzytelnia użytkownika, a następnie żąda listy szablonów profilów, dla których uwierzytelniony użytkownik może się zarejestrować:

    GET /CertificateManagement/api/v1.0/profiletemplates.
    
  2. Klient wyświetli użytkownikowi listę wynikową. Użytkownik wybiera szablon profilu wirtualnej karty inteligentnej o nazwie "Wirtualna karta inteligentna VPN" i identyfikator 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1 UUID.

  3. Klient pobiera zasady rejestracji wybranego szablonu profilu przy użyciu funkcji UUID zwróconej w poprzednim kroku:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
    
  4. Klient analizuje pole DataCollection w zwracanych zasadach, zwróć uwagę na to, że jest wyświetlany pojedynczy element zbierania danych zatytułowany "Przyczyna żądania". Klient zauważa również, że flaga collectComments jest ustawiona na wartość false, więc nie monituje użytkownika o wprowadzenie żadnego.

  5. Po wprowadzeniu przez użytkownika przyczyny wymagania certyfikatów klient tworzy żądanie:

    POST /CertificateManagement/api/v1.0/requests
    
    {
        "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
        "type":"Enroll",
        "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
        "comment":""
    }
    
  6. Serwer pomyślnie tworzy żądanie i zwraca jego URI do klienta: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5 .

  7. Klient pobiera obiekt żądania, wywołując zwrócony identyfikator URI:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
  8. Klient sprawdza, czy właściwość stanu w żądaniu jest ustawiona na zatwierdzona. Wykonywanie żądania może rozpocząć się.

  9. Klient sprawdza żądanie, aby sprawdzić, czy istnieje już skojarzona z nim karta inteligentna, analizując zawartość parametru newsmartcarduuid.

  10. Ponieważ zawiera on tylko pusty identyfikator GUID, klient musi użyć istniejącej karty, która nie jest jeszcze w użyciu przez usługę MIM CM, lub utworzyć ją, jeśli szablon profilu jest konfigurowany dla wirtualnych kart inteligentnych.

  11. Ponieważ ten drugi został wskazany klientowi za pośrednictwem początkowego zapytania o szablony profilów, które można zarejestrować (krok 1), klient musi teraz utworzyć wirtualne urządzenie karty inteligentnej.

  12. Klient pobiera zasady karty inteligentnej z szablonu profilu. Używa on uuid szablonu, który został wybrany w kroku 3:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    
  13. Zasady karty inteligentnej zawierają domyślny klucz administratora karty we właściwości DefaultAdminKeyHex. Podczas tworzenia karty inteligentnej klient musi ustawić początkowy klucz administratora karty inteligentnej na ten klucz.

  14. Podczas tworzenia urządzenia karty inteligentnej klient musi przypisać je do żądania:

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    
  15. Serwer odpowiada klientowi identyfikatorem URI na nowo utworzony obiekt karty inteligentnej: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644 .

  16. Klient pobiera obiekt karty inteligentnej:

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    
  17. Sprawdzając wartość flagi przejmujeadminkey w zasadach karty inteligentnej uzyskanych w kroku 12, klient wie, że musi odeśleć klucz administratora.

  18. Klient pobiera proponowany klucz administratora:

    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. Aby ustawić klucz administratora, klient musi uwierzytelnić się na karcie jako administrator. W tym celu klient żąda żądania uwierzytelnienia z karty inteligentnej i przesyła je do serwera:

    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
    

    Serwer wysyła odpowiedź na żądanie w treści odpowiedzi HTTP. Znajdź szesnastkowym ciąg wyzwania, przekonwertuj go na base64 i przekaż go jako parametr w adresie URL. Adres URL zwraca inną odpowiedź, która musi zostać przekonwertowana z powrotem na format szesnastkowym.

  20. Serwer wysyła odpowiedź na żądanie w treści odpowiedzi HTTP, a klient używa jej do chłoniania klucza administratora.

  21. Klient zwraca uwagę, że użytkownik musi podać żądany numer PIN, sprawdzając pole UserPinOption w zasadach karty inteligentnej.

  22. Po wprowadzeniu żądanego numeru PIN do okna dialogowego klient przeprowadza uwierzytelnianie typu challenge-response zgodnie z instrukcje w kroku 19. Jedyną różnicą jest to, że flaga zdywersyfikowana powinna teraz mieć wartość 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. Klient ustawia żądany numer PIN użytkownika za pomocą odpowiedzi odebranej z serwera.

  24. Klient jest teraz gotowy do generowania żądań certyfikatów. Wysyła zapytanie do parametrów generowania certyfikatu szablonu profilu, aby określić sposób generowania kluczy/żądań.

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
    
  25. Serwer odpowiada pojedynczym obiektem CertificateRequestGenerationOptions serializowanym w postaci JSON. Obiekt zawiera parametry dotyczące możliwości eksportowania klucza, przyjazną nazwę certyfikatu, algorytm wyznaczania wartości skrótu, algorytm klucza, rozmiar klucza i tak dalej. Klient używa tych parametrów do wygenerowania żądania certyfikatu.

  26. Żądanie pojedynczego certyfikatu jest przesyłane do serwera. Klient może dodatkowo określić hasło PFX, które powinno być używane do odszyfrowywania dowolnych obiektów blob PFX, gdy szablon certyfikatu określa archiwizowanie certyfikatów urzędu certyfikacji, czyli urząd certyfikacji generuje parę kluczy, a następnie wysyła je do klienta. Klient może również dodać kilka komentarzy.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    
  27. Po kilku sekundach serwer odpowie pojedynczym obiektem Microsoft.Clm.Shared.Certificate serializowanym w postaci JSON. Sprawdzając flagę isPkcs7, klient dowie się, że ta odpowiedź nie jest obiektem blob PFX. Klient wyodrębnia obiekt blob przez zdekodowanie ciągu pkcs7 base64 i instaluje go.

  28. Klient oznacza żądanie jako ukończone.

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