Sdílet prostřednictvím


Ukázkový návod k registraci

Tento článek popisuje kroky potřebné k provedení samoobslužné registrace virtuální čipové karty. Zobrazí se automaticky schválená žádost s pin kódem nastaveným uživatelem.

  1. Klient ověří uživatele a pak požádá o seznam šablon profilů, pro které se ověřený uživatel může zaregistrovat:

    GET /CertificateManagement/api/v1.0/profiletemplates.
    
  2. Klient zobrazí uživateli výsledný seznam. Uživatel vybere šablonu profilu virtuální čipové karty vSC s názvem Virtual Smartcard VPN a UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

  3. Klient načte zásady registrace vybrané šablony profilu pomocí UUID vráceného v předchozím kroku:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
    
  4. Klient analyzuje pole DataCollection ve vrácené zásadě a povzorňuje, že se zobrazí jedna položka kolekce dat s názvem "Důvod požadavku". Klient si také všimněte, že příznak collectComments je nastavený na false, takže uživatele nevyzve k zadání žádné.

  5. Jakmile uživatel zadá důvod vyžadování certifikátů, klient vytvoří požadavek:

    POST /CertificateManagement/api/v1.0/requests
    
    {
        "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
        "type":"Enroll",
        "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
        "comment":""
    }
    
  6. Server úspěšně vytvoří požadavek a vrátí klientovi identifikátor URI požadavku: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

  7. Klient načte objekt požadavku voláním vráceného identifikátoru URI:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
    
  8. Klient ověří, že vlastnost state v požadavku je nastavená na schváleno. Může začít provádění požadavku.

  9. Klient prozkoumá požadavek a zjistí, jestli už k požadavku není přidružená čipová karta, a to analýzou obsahu parametru newsmartcarduuid .

  10. Vzhledem k tomu, že obsahuje pouze prázdný identifikátor GUID, musí klient buď použít existující kartu, kterou ještě nepoužívá MIM CM, nebo ji vytvořit, pokud je šablona profilu nakonfigurována pro virtuální čipové karty.

  11. Vzhledem k tomu, že druhá možnost byla klientovi označena prostřednictvím počátečního dotazu na šablony profilu pro registraci (krok 1), musí teď klient vytvořit virtuální zařízení čipové karty.

  12. Klient načte zásadu čipové karty ze šablony profilu. Používá UUID šablony vybrané v kroku 3:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    
  13. Zásada čipové karty obsahuje výchozí klíč správce pro kartu ve vlastnosti DefaultAdminKeyHex . Při vytváření čipové karty musí klient nastavit počáteční klíč správce čipové karty na tento klíč.

  14. Po vytvoření zařízení s čipovou kartou ho klient musí přiřadit k požadavku:

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    
  15. Server odpoví klientovi pomocí identifikátoru URI nově vytvořeného objektu čipové karty: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

  16. Klient načte objekt čipové karty:

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644
    
  17. Díky kontrole hodnoty příznaku diverzifikaceadminkey v zásadách čipové karty získaných v kroku 12 klient ví, že musí klíč správce diverzifikovat.

  18. Klient načte navrhovaný klíč správce:

    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 se musí ověřit na kartě jako správce, aby mohl nastavit klíč správce. Za tímto účelem klient požádá o ověřovací výzvu z čipové karty a odešle ji na 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
    

    Server odešle odpověď na výzvu v textu odpovědi HTTP. Vyhledejte šestnáctkový řetězec výzvy, převeďte ho na base64 a předejte ho jako parametr v adrese URL. Adresa URL vrátí další odpověď, která se musí převést zpět do šestnáctkového formátu.

  20. Server odešle odpověď na výzvu v textu odpovědi HTTP a klient ji použije k diverzifikaci klíče správce.

  21. Klient si všímá, že uživatel musí zadat požadovaný pin tím, že zkontroluje pole UserPinOption v zásadách čipové karty.

  22. Jakmile uživatel zadá požadovaný pin kód do dialogového okna, klient provede ověřování výzvou a odpovědí, jak je popsáno v kroku 19, přičemž jediným rozdílem je, že různorodý příznak by teď měl být nastaven na hodnotu 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 použije odpověď přijatou ze serveru k nastavení požadovaného pin kódu uživatele.

  24. Klient je teď připraven generovat žádosti o certifikáty. Dotazuje se na parametry generování certifikátu šablony profilu a určí, jak se mají generovat klíče nebo požadavky.

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
    
  25. Server odpoví jedním objektem CertificateRequestGenerationOptions serializovaným ve formátu JSON. Objekt obsahuje parametry pro exportovatelnost klíče, popisný název certifikátu, algoritmus hash, algoritmus klíče, velikost klíče atd. Klient používá tyto parametry k vygenerování žádosti o certifikát.

  26. Žádost o jeden certifikát se odešle na server. Klient může navíc zadat heslo PFX, které by se mělo použít k dešifrování všech objektů blob PFX, když šablona certifikátu určuje archivaci certifikátů na certifikační autoritě, to znamená, že certifikační autorita vygeneruje pár klíčů a pak ho odešle klientovi. Klient se také může rozhodnout přidat nějaké komentáře.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata
    
    {
       "pfxpassword":"",
       "certificaterequests":[
           "MIIDZDC…”
        ]
    }   
    
  27. Po několika sekundách server odpoví jedním objektem Microsoft.Clm.Shared.Certificate serializovaným ve formátu JSON. Kontrolou příznaku isPkcs7 klient zjistí, že tato odpověď není objektem blob PFX. Klient extrahuje objekt blob tak, že base64 dekóduje řetězec pkcs7 a nainstaluje ho.

  28. Klient označí požadavek jako dokončený.

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