Przewodnik po przykładowej rejestracji

W tym artykule przedstawiono kroki wymagane do przeprowadzenia rejestracji samoobsługowej wirtualnej karty inteligentnej. Przedstawia ono automatycznie zatwierdzone żądanie z numerem PIN ustawionym przez użytkownika.

1. Klient uwierzytelnia użytkownika, a następnie żąda listy szablonów profilów, na które może zapisać się uwierzytelniony użytkownik.

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

2. Klient wyświetla wynikową listę użytkownikowi. Użytkownik wybiera szablon profilu vSC (wirtualnej karty inteligentnej) o nazwie "Virtual Smartcard VPN" i UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

3. Użytkownik pobiera zasady rejestracji dla wybranego szablonu profilu, korzystając z identyfikatora UUID zwróconego w poprzednim kroku.

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

4. Klient analizuje pole DataCollection w zwróconych zasadach, zauważając, że zostanie wyświetlony pojedynczy element zbierania danych zatytułowany "Przyczyna żądania". Klient zauważa również, że flaga collectComments jest ustawiona na false, więc nie monituje użytkownika o wprowadzenie żadnych.

5. Po wprowadzeniu 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 utworzy żądanie i zwróci identyfikator URI żądania 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 zatwierdzoną. Wykonanie żądania może się rozpocząć.

9. Klient sprawdza żądanie, aby sprawdzić, czy istnieje już karta inteligentna skojarzona z żądaniem, 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 używana przez program MIM CM, lub utworzyć go, jeśli szablon profilu jest skonfigurowany dla wirtualnych kart inteligentnych.

11. Ponieważ ten ostatni został wskazany klientowi za pośrednictwem początkowego zapytania dotyczącego szablonów profilów możliwych do zarejestrowania (krok 1), klient musi teraz utworzyć wirtualne urządzenie karty inteligentnej.

12. Klient pobiera zasady karty inteligentnej z szablonu profilu. Używa identyfikatora UUID szablonu wybranego 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. Po utworzeniu urządzenia karty inteligentnej klient musi przypisać go 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 nowo utworzonego obiektu 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 diversifyadminkey w zasadach karty inteligentnej uzyskanych w kroku 12, klient wie, że należy zdywersyfikować 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. Klient musi uwierzytelnić się na karcie jako administrator, aby ustawić klucz administratora. W tym celu klient żąda żądania uwierzytelnienia z karty inteligentnej i przesyła go 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ź ciąg wyzwania szesnastkowego, przekonwertuj na base64 i przekaż go jako parametr w adresie URL. Adres URL zwraca kolejną odpowiedź, która musi zostać przekonwertowana z powrotem na format szesnastkowy.

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

21. Klient zauważa, ż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 wykonuje uwierzytelnianie w odpowiedzi na żądanie zgodnie z opisem w kroku 19, a jedyną różnicą jest to, że zdywersyfikowana flaga powinna być teraz ustawiona na 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 używa odpowiedzi otrzymanej z serwera, aby ustawić żądany numer PIN użytkownika.

24. Klient jest teraz gotowy do generowania żądań certyfikatów. Pyta o parametry generowania certyfikatu szablonu profilu, aby ustalić, jak powinny być generowane klucze/żądania.

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

25. Serwer odpowiada za pomocą pojedynczego obiektu CertificateRequestGenerationOptions w formacie JSON. Obiekt zawiera parametry umożliwiające eksportowanie klucza, przyjazną nazwę certyfikatu, algorytm tworzenia skrótów, algorytm klucza, rozmiar klucza itd. Klient używa tych parametrów do wygenerowania żądania certyfikatu.

26. Jedno żądanie certyfikatu jest przesyłane do serwera. Klient może dodatkowo określić hasło PFX, które powinno służyć do odszyfrowywania dowolnych obiektów blob PFX, gdy szablon certyfikatu określa archiwizowanie certyfikatów w urzędzie certyfikacji, czyli urząd certyfikacji generuje parę kluczy, a następnie wysyła go do klienta. Klient może również dodać komentarze.

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

27. Po kilku sekundach serwer odpowiada za pomocą pojedynczego obiektu Microsoft.Clm.Shared.Certificate serializowanego w formacie JSON. Sprawdzając flagę isPkcs7 , klient dowiaduje się, że ta odpowiedź nie jest obiektem blob PFX. Klient wyodrębnia obiekt blob przez dekodowanie base64 ciągu pkcs7 i instaluje go.

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

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