Guia passo a passo para inscrição de amostra

Este artigo mostra as etapas necessárias para executar uma inscrição de autoatendimento de cartão inteligente virtual. Ele mostra uma solicitação aprovada automaticamente com um PIN definido pelo usuário.

1. O cliente autentica o usuário e solicita uma lista de modelos de perfil para os quais o usuário autenticado pode se registrar:

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

2. O cliente exibe a lista resultante para o usuário. O usuário seleciona um modelo de perfil vSC (cartão inteligente virtual) com o nome "Virtual Smartcard VPN" e o UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

3. O cliente recupera a política de registro do modelo de perfil selecionado usando a UUID retornada na etapa anterior:

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

4. O cliente analisa o campo DataCollection na política retornada, observando que um único item de coleta de dados intitulado "Motivo da Solicitação" é exibido. O cliente também observa que o sinalizador collectComments está definido como false, portanto, ele não solicita que o usuário insira comentários.

5. Depois que o usuário tiver inserido o motivo para exigir os certificados, o cliente criará uma solicitação:

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

6. O servidor cria a solicitação com êxito e retorna o URI da solicitação para o cliente: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

7. O cliente recupera o objeto de solicitação chamando o URI retornado:

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

8. O cliente verifica se a propriedade do estado da solicitação está definida como aprovada. A execução da solicitação pode começar.

9. O cliente examina a solicitação para ver se há um cartão inteligente já associado à solicitação analisando o conteúdo do parâmetro newsmartcarduuid.

10. Como ele contém apenas um GUID vazio, o cliente deve usar um cartão existente ainda não em uso pelo MIM CM ou criar um se o modelo de perfil estiver sendo configurado para cartões inteligentes virtuais.

11. Como este último foi indicado ao cliente por meio da consulta inicial para modelos de perfil registráveis (etapa 1), o cliente agora deve criar um dispositivo de cartão inteligente virtual.

12. O cliente recupera a política de cartão inteligente do template de perfil. Ele usa a UUID do modelo selecionado na etapa 3:

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

13. A política de cartão inteligente contém a chave de administrador padrão para o cartão na propriedade DefaultAdminKeyHex. Ao criar o cartão inteligente, o cliente deve definir a chave de administrador inicial do cartão inteligente para essa chave.

14. Ao criar o dispositivo de cartão inteligente, o cliente deve atribuí-lo à solicitação:

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

15. O servidor responde ao cliente com um URI para o objeto de cartão inteligente recém-criado: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

16. O cliente recupera o objeto de cartão inteligente:

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

17. Ao verificar o valor do sinalizador diversifyadminkey na política de cartão inteligente obtida na etapa 12, o cliente sabe que precisa diversificar a chave de administrador.

18. O cliente recupera a chave de administrador 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. O cliente deve autenticar-se no cartão como administrador para definir a chave de administrador. Para fazer isso, o cliente solicita um desafio de autenticação do cartão inteligente e o envia ao servidor:

    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
    

    O servidor envia a resposta de desafio no corpo da resposta HTTP. Localize a cadeia de caracteres de desafio hexadecimal, converta em base64 e passe-a como um parâmetro na URL. A URL retorna outra resposta, que deve ser convertida de volta para o formato hexadecimal.

20. O servidor envia a resposta de desafio no corpo da resposta HTTP e o cliente a usa para diversificar a chave de administrador.

21. O cliente observa que o usuário deve fornecer o pin desejado inspecionando o campo UserPinOption na política de cartão inteligente.

22. Depois que o usuário inseriu o pin desejado em uma caixa de diálogo, o cliente executa uma autenticação de desafio-resposta conforme descrito na etapa 19, com a única diferença é que o sinalizador diversificado agora deve ser definido como 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. O cliente usa a resposta recebida do servidor para definir o pin de usuário desejado.

24. O cliente agora está pronto para gerar solicitações de certificado. Ele consulta os parâmetros de geração de certificado do modelo de perfil para determinar como as chaves/solicitações devem ser geradas.

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

25. O servidor responde com um único objeto CertificateRequestGenerationOptions serializado em JSON. O objeto inclui parâmetros para a exportabilidade da chave, nome amigável do certificado, algoritmo de hash, algoritmo de chave, tamanho da chave e assim por diante. O cliente usa esses parâmetros para gerar uma solicitação de certificado.

26. A solicitação de certificado único é enviada ao servidor. Além disso, o cliente pode especificar uma senha PFX que deve ser usada para descriptografar qualquer bloco PFX quando o modelo de certificado especifica o arquivamento dos certificados na Autoridade Certificadora (AC), ou seja, a AC gera o par de chaves e, em seguida, envia-o ao cliente. O cliente também pode optar por adicionar alguns comentários.

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

27. Após alguns segundos, o servidor responde com um único objeto Microsoft.Clm.Shared.Certificate serializado por JSON. Ao verificar o sinalizador isPkcs7, o cliente descobre que essa resposta não é um blob PFX. O cliente extrai o blob decodificação base64 da cadeia de caracteres pkcs7 e o instala.

28. O cliente marca a solicitação como concluída.

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