Procedura dettagliata di registrazione di esempio

Questo articolo illustra i passaggi necessari per eseguire una registrazione self-service di smart card virtuale. Viene mostrata la richiesta di approvazione automatica con un PIN impostato dall’utente.

1. Il client autentica l'utente, quindi richiede un elenco di modelli di profilo a cui l'utente autenticato può registrarsi:

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

2. Il client visualizza l'elenco risultante all'utente. L'utente seleziona un modello di profilo vSC (smart card virtuale) con nome "VPN smart card virtuale" e UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

3. Il client recupera i criteri di registrazione del modello di profilo selezionato tramite l'UUID restituito nel passaggio precedente:

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

4. Il client analizza il campo DataCollection nei criteri restituiti, notando che viene visualizzato un singolo elemento di raccolta dati denominato "Motivo richiesta". Il client nota anche che il flag collectComments è impostato su false, quindi non richiede all'utente di immettere alcun valore.

5. Una volta che l’utente ha immesso il motivo per la richiesta di certificati, il client crea una richiesta:

   POST /CertificateManagement/api/v1.0/requests
   
   {
       "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
       "type":"Enroll",
       "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
       "comment":""
   }
   

6. Il server crea correttamente la richiesta e restituisce l'URI della richiesta al client: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

7. Il client recupera l'oggetto richiesta chiamando l'URI restituito:

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

8. Il client verifica che la proprietà di stato nella richiesta sia impostata su approvata. L'esecuzione della richiesta può iniziare.

9. Il client esamina la richiesta per verificare se è già associata una smart card alla richiesta analizzando il contenuto del parametro newsmartcarduuid .

10. Poiché contiene solo un GUID vuoto, il client deve usare una scheda esistente non già in uso da CM MIM oppure crearne una se il modello di profilo è configurato per le smart card virtuali.

11. Poiché quest'ultimo è stato indicato al client tramite la query iniziale per i modelli di profilo registrabili (passaggio 1), il client deve creare adesso un dispositivo smart card virtuale.

12. Il client recupera i criteri della smart card dal modello di profilo. Usa l'UUID del modello selezionato nel passaggio 3:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
    

13. Il criterio della smart card contiene la chiave di amministrazione predefinita per la scheda nella proprietà DefaultAdminKeyHex . Quando si crea la smart card, il client deve impostare la chiave di amministrazione iniziale della smart card su questa chiave.

14. Al momento della creazione del dispositivo di smart card, il client deve assegnarlo alla richiesta:

    POST /CertificateManagement/api/v1.0/smartcards
    
    {
        "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
        "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
    }
    

15. Il server risponde al client con un URI all'oggetto smart card appena creato: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

16. Il client recupera l'oggetto smart card:

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

17. Controllando il valore del flag diversifiadminkey nei criteri di smart card ottenuti nel passaggio 12, il client sa che deve diversificazione della chiave di amministrazione.

18. Il client recupera la chiave di amministratore proposta:

    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. Il client deve autenticarsi presso la scheda come amministratore per impostare la chiave di amministrazione. A tale scopo, il client effettua una richiesta di autenticazione di smart card e la invia al 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
    

    Il server invia la risposta alla richiesta nel corpo della risposta HTTP. Individuare la stringa di richiesta esadecimale, convertirla in base64 e trasferirla come parametro nell'URL. L'URL restituisce un'altra risposta, che deve essere convertita in formato esadecimale.

20. Il server invia la risposta alla richiesta nel corpo della risposta HTTP e il client la utilizza per diversificare la chiave di amministrazione.

21. Il client nota che l'utente deve specificare il pin desiderato controllando il campo UserPinOption nei criteri della smart card.

22. Dopo che l'utente ha immesso il pin desiderato in una finestra di dialogo, il client esegue un'autenticazione challenge-response come descritto nel passaggio 19, con l'unica differenza che il flag diversificato deve ora essere impostato su 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. Il client utilizza la risposta ricevuta dal server per impostare il PIN utente desiderato.

24. Il client è ora pronto per generare richieste di certificati. Esegue query dei parametri di generazione del certificato del modello di profilo per determinare la modalità di generazione delle chiavi/richieste.

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

25. Il server risponde con un singolo oggetto CertificateRequestGenerationOptions serializzato JSON. L'oggetto include parametri per l'esportabilità della chiave, il nome descrittivo del certificato, l'algoritmo hash, l'algoritmo di chiave, le dimensioni della chiave e così via. Il client utilizza questi parametri per generare una richiesta di certificato.

26. La richiesta del singolo certificato viene inviata al server. Il client può inoltre specificare una password PFX che deve essere usata per decrittografare eventuali BLOB PFX quando il modello di certificato specifica l'archiviazione dei certificati nella CA, ovvero la CA genera la coppia di chiavi e quindi la invia al client. Il client può anche scegliere di aggiungere alcuni commenti.

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

27. Dopo alcuni secondi, il server risponde con un singolo oggetto Microsoft.Clm.Shared.Certificate serializzato JSON. Controllando il flag isPkcs7 , il client apprende che questa risposta non è un BLOB PFX. Il client estrae il BLOB decodificando la stringa pkcs7 in base64 e lo installa.

28. Il client contrassegna la richiesta come completata.

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