Instruções de inscrição de exemplo

Artigo
09/14/2023

Este artigo mostra os passos necessários para efetuar uma inscrição self-service de smart card virtual. Mostra um pedido aprovado automaticamente com um PIN definido pelo utilizador.

O cliente autentica o utilizador e, em seguida, pede uma lista de modelos de perfil para os quais o utilizador autenticado pode inscrever-se:
```
GET /CertificateManagement/api/v1.0/profiletemplates.
```
O cliente apresenta a lista resultante ao utilizador. O utilizador seleciona um modelo de perfil vSC (smart card virtual) com o nome "Virtual Smartcard VPN" e UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.
O cliente obtém a política de inscrição do modelo de perfil selecionado com o UUID devolvido no passo anterior:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
```
O cliente analisa o campo DataCollection na política devolvida, observando que é apresentado um único item de recolha de dados intitulado "Motivo do Pedido". O cliente também nota que o sinalizador collectComments está definido como falso, pelo que não pede ao utilizador para introduzir nenhum.

Depois de o utilizador ter introduzido o motivo para exigir os certificados, o cliente cria um pedido:

POST /CertificateManagement/api/v1.0/requests

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

O servidor cria o pedido com êxito e devolve o URI do pedido ao cliente: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

O cliente obtém o objeto de pedido ao chamar o URI devolvido:

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

O cliente verifica se a propriedade state no pedido está definida como aprovada. A execução do pedido pode começar.
O cliente examina o pedido para ver se já existe um smart card associado ao pedido ao analisar o conteúdo do parâmetro newsmartcarduuid .
Uma vez que contém apenas um GUID vazio, o cliente tem de utilizar um cartão existente que ainda não esteja a ser utilizado pelo CM do MIM ou criar um se o modelo de perfil estiver a ser configurado para smart cards virtuais.
Uma vez que este último foi indicado ao cliente através da consulta inicial para modelos de perfil inscrições (passo 1), o cliente tem agora de criar um dispositivo smart card virtual.
O cliente obtém a política de smart card a partir do modelo de perfil. Utiliza o UUID do modelo selecionado no passo 3:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
```
A política de smart card contém a chave de administrador predefinida para o cartão na propriedade DefaultAdminKeyHex . Ao criar o smart card, o cliente tem de definir a chave de administração inicial do smart card para esta chave.

Após a criação do dispositivo smart card, o cliente tem de atribuí-lo ao pedido:

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 smart card recentemente criado: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

O cliente obtém o objeto de smart card:

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

Ao verificar o valor do sinalizador diversificaçãoadminkey na política de smart card obtida no passo 12, o cliente sabe que tem de diversificar a chave de administração.

O cliente obtém 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 tem de se autenticar no cartão como administrador para definir a chave de administrador. Para tal, o cliente solicita um desafio de autenticação do smart card e submete-o 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 de resposta HTTP. Localize a cadeia de desafio hexadecimal, converta-a em base64 e transmita-a como um parâmetro no URL. O URL devolve outra resposta, que tem de ser convertida novamente para o formato hexadecimal.
O servidor envia a resposta de desafio no corpo de resposta HTTP e o cliente utiliza-a para diversificar a chave de administração.
O cliente nota que o utilizador tem de fornecer o pin pretendido ao inspecionar o campo UserPinOption na política de smart card.
Depois de o utilizador ter introduzido o pin pretendido numa caixa de diálogo, o cliente efetua uma autenticação de resposta de desafio, conforme descrito no passo 19, sendo que a única diferença é que o sinalizador diversificado deve agora ser definido como verdadeiro:
```
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 utiliza a resposta recebida do servidor para definir o pin do utilizador pretendido.
O cliente está agora pronto para gerar pedidos de certificado. Consulta os parâmetros de geração de certificados do modelo de perfil para determinar como as chaves/pedidos devem ser gerados.
```
GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
```
O servidor responde com um único objeto CertificateRequestGenerationOptions serializado JSON. O objeto inclui parâmetros para a exportabilidade da chave, nome amigável do certificado, algoritmo hash, algoritmo de chave, tamanho da chave, etc. O cliente utiliza estes parâmetros para gerar um pedido de certificado.
O pedido de certificado único é submetido para o servidor. O cliente pode especificar adicionalmente uma palavra-passe PFX que deve ser utilizada para desencriptar quaisquer blobs PFX quando o modelo de certificado especifica arquivar os certificados na AC, ou seja, a AC gera o par de chaves e, em seguida, envia-o para o 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 fica a saber que esta resposta não é um blob PFX. O cliente extrai o blob por base64 descodificando a cadeia pkcs7 e instala-a.

O cliente marca o pedido como concluído.

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

{
    "status":"Completed"
}

Partilhar via

Instruções de inscrição de exemplo

Comentários

Recursos adicionais