Пример пошагового руководства по регистрации

Статья
09/14/2023

В этой статье описаны действия, необходимые для самостоятельной регистрации виртуальных смарт-карт. Здесь показан самозаверяющий запрос с PIN-кодом, который задает пользователь.

Клиент выполняет проверку подлинности пользователя, а затем запрашивает список шаблонов профилей, который может зарегистрировать пользователь, прошедший проверку подлинности:
```
GET /CertificateManagement/api/v1.0/profiletemplates.
```
Клиент показывает полученный список пользователю. Пользователь выбирает шаблон профиля vSC (виртуальная смарт-карта) с именем Virtual Smartcard VPN и UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.
Клиент получает политику регистрации выбранного шаблона профиля с помощью идентификатора UUID, возвращенного на предыдущем этапе:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll
```
Клиент анализирует поле DataCollection в возвращаемой политике, отмечая, что отображается один элемент сбора данных с названием "Причина запроса". Клиент также отмечает, что для флага collectComments задано значение false, поэтому пользователю не предлагается вводить какие-либо данные.

Когда пользователь укажет причину запроса сертификатов, клиент создает запрос:

POST /CertificateManagement/api/v1.0/requests

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

Сервер успешно создает запрос и возвращает клиенту универсальный код ресурса (URI) запроса: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.
Клиент получает объект запроса, вызывая полученный URI:
```
GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5
```
Клиент проверяет, что свойству состояния в запросе присвоено значение "Утверждено". Может начаться выполнение запроса.
Клиент проверяет запрос на наличие смарт-карты, уже связанной с запросом, анализируя содержимое параметра newsmartcarduuid .
Так как он содержит только пустой GUID, клиент должен либо использовать существующую карту, еще не используемую MIM CM, либо создать ее, если шаблон профиля настроен для виртуальных смарт-карт.
Поскольку последний указан клиенту с помощью исходного запроса для регистрируемых шаблонов профиля (этап 1), теперь клиент должен создать устройство для виртуальной смарт-карты.
Клиент получает политику смарт-карт из шаблона профиля. Он использует UUID шаблона, выбранного на шаге 3:
```
GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards
```
Политика смарт-карт содержит ключ администратора по умолчанию для карточки в свойстве DefaultAdminKeyHex . При создании смарт-карты клиент должен указать в этом ключе исходный ключ администратора.

После создания устройства смарт-карты клиент должен назначить его запросу:

POST /CertificateManagement/api/v1.0/smartcards

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

Сервер отвечает клиенту с помощью универсального кода ресурса (URI) для только что созданного объекта смарт-карты: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

Клиент получает объект смарт-карты:

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

Проверив значение флага diversifyadminkey в политике смарт-карт, полученной на шаге 12, клиент знает, что должен диверсифицировать ключ администратора.

Клиент получает предложенный ключ администратора:

GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/diversifiedkey?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9

Клиент должен пройти проверку подлинности для карточки от имени администратора, чтобы задать ключ администратора. Для этого клиент запрашивает задание проверки подлинности у смарт-карты и отправляет его на сервер:
```
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
```
Сервер отправляет ответ на запрос в тексте ответа HTTP. Найдите шестнадцатеричную строку запроса, преобразуйте ее в base64 и передайте ее в качестве параметра в URL-адрес. URL-адрес возвращает другой ответ, который необходимо преобразовать обратно в шестнадцатеричный формат.
Сервер отправляет ответ на запрос в тексте ответа HTTP, а клиент использует его для изменения ключа администратора.
Клиент отмечает, что пользователь должен предоставить нужный пин-код, проверив поле UserPinOption в политике смарт-карт.
После того как пользователь введет нужный пин-код в диалоговом окне, клиент выполняет проверку подлинности с запросом и ответом, как описано на шаге 19. Единственное отличие заключается в том, что для диверсифицированного флага теперь должно быть задано значение 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
```
Клиент использует ответ, полученный с сервера, чтобы задать PIN-код пользователя.
Теперь клиент готов к созданию запросов на сертификаты. Он запрашивает параметры создания сертификатов шаблонов профиля, чтобы определить, как должны создаваться ключи и запросы.
```
GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.
```
Сервер отвечает одним сериализованным объектом CertificateRequestGenerationOptions в формате JSON. Объект содержит параметры для экспортируемости ключа, понятного имени сертификата, алгоритма хэширования, алгоритма ключа, размера ключа и т. д. Клиент использует эти параметры для создания запроса сертификата.
На сервер отправляется один запрос сертификата. Клиент может дополнительно указать пароль PFX, который следует использовать для расшифровки любых больших двоичных объектов PFX, если шаблон сертификата указывает архивирование сертификатов в ЦС, то есть ЦС создает пару ключей, а затем отправляет ее клиенту. Клиент также может добавить примечания.
```
POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata

{
   "pfxpassword":"",
   "certificaterequests":[
       "MIIDZDC…”
    ]
}   
```
Через несколько секунд сервер отвечает одним сериализованным объектом Microsoft.Clm.Shared.Certificate в формате JSON. Проверив флаг isPkcs7 , клиент узнает, что этот ответ не является большим двоичным объектом PFX. Клиент извлекает большой двоичный объект путем декодирования строки pkcs7 в base64 и устанавливает его.

Клиент помечает запрос как завершенный.

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

{
    "status":"Completed"
}

Поделиться через

Пример пошагового руководства по регистрации

Обратная связь

Дополнительные ресурсы