Passo a passo do registro de exemplo

Artigo
09/14/2023

Este artigo mostra as etapas necessárias para executar um registro de autoatendimento de cartão inteligente virtual. Mostra uma solicitação de aprovação automática com um PIN definido pelo usuário.

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.
```
O cliente exibe a lista resultante ao usuário. O usuário seleciona um modelo de perfil vSC (cartão inteligente virtual) com o nome "VPN de cartão inteligente virtual" e UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.
O cliente recupera a política de registro do modelo de perfil selecionado usando o UUID retornado na etapa anterior:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
```
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 nenhum.

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

POST /CertificateManagement/api/v1.0/requests

{
    "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
    "type":"Enroll",
    "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
    "comment":""
}

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.

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

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

O cliente verifica se a propriedade state na solicitação está definida como aprovada. A execução da solicitação pode começar.
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 .
Como ele contém apenas um GUID vazio, o cliente deve usar um cartão existente que ainda não está em uso pelo MIM CM ou criar um se o modelo de perfil estiver sendo configurado para cartões inteligentes virtuais.
Como este último foi indicado ao cliente por meio da consulta inicial para os modelos de perfil registráveis (etapa 1), agora ele deve criar um dispositivo de Cartão Inteligente Virtual.
O cliente recupera a política de cartão inteligente do modelo de perfil. Ele usa o UUID do modelo que foi selecionado na etapa 3:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
```
A política de cartão inteligente contém a chave de administrador padrão para o cartão na propriedade DefaultAdminKeyHex . Quando criar o cartão inteligente, o cliente deve definir a chave de administração inicial do cartão inteligente para essa chave.

Após a criação do dispositivo de cartão inteligente, ele deve atribuí-lo à solicitação:

POST /CertificateManagement/api/v1.0/smartcards

{
    "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
    "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
}

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.

O cliente recupera o objeto de cartão inteligente:

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

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

O cliente recupera a chave de administração 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

O cliente deve autenticar ao cartão como administrador para definir a chave de administração. Para fazer isso, ele 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 do 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.
O servidor envia a resposta do desafio no corpo da resposta HTTP e o cliente o utiliza para diversificar a chave de administração.
O cliente observa que o usuário deve fornecer o pin desejado inspecionando o campo UserPinOption na política de cartão inteligente.
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
```
O cliente usa a resposta recebida do servidor para definir o pin do usuário desejado.
O cliente agora está pronto para gerar solicitações de certificado. Ele consulta os parâmetros de geração de certificado de modelo do perfil para determinar como as solicitações/chaves devem ser geradas.
```
GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
```
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.
A solicitação de certificado única é enviada ao servidor. Além disso, o cliente pode especificar uma senha PFX que deve ser usada para descriptografar qualquer blobs PFX quando o modelo de certificado especifica o arquivamento dos certificados na 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…”
    ]
}   
```
Após alguns segundos, o servidor responde com um único objeto Microsoft.Clm.Shared.Certificate serializado em 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 instala-o.

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

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

{
    "status":"Completed"
}

Compartilhar via

Passo a passo do registro de exemplo

Comentários

Recursos adicionais