Аутентификация Оператора на Центре Идентификации

Аутентификация Оператора производится по сертификату (HTTPS с аутентификацией клиента).

Для получения AccessToken используется OAuth сценарий с использованием кода авторизации. Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework

Администратор должен предварительно настроить OAuth клиента на сервере:

• создание нового клиента:

Add-IdsClient -Identifier testClient -Name testClient -Description "Test Client Description" -RedirectUri urn:ietf:wg:oauth:2.0:oob:auto -AllowedFlow ResourceOwner,AuthorizationCode

• изменение настройки существующего клиента:

Set-IdsClient -ClientId testClient -RedirectUri urn:ietf:wg:oauth:2.0:oob:auto -AllowedFlow ResourceOwner,AuthorizationCode

Примечание

Значение RedirectUri может содежать URL адреса, как со стандартной HTTP схемой https://, так и со схемами, зарегистрированными в ОС для конкретных приложений, например, my.app.sheme://oauth-redirect-callback. Использование подобных схем позволяет автоматически активировать соответствующее приложение при получении перенаправления в браузере. Если приложение может поднять на своей стороне HTTP-слушателя, то допустимо использовать в RedirectUri в качестве имени хоста значение localhost с указанием TCP-порта, на котором осуществляется прослушивание. Если же приложение самостоятельно управляет процессом отправки HTTP-запросов на конечные точки авторизации (/authorize и /authorize/certificate) и имеет доступ к ответам веб-сервера, то в качестве RedirectUri можно использовать не URL адреса, а произвольные URI, например, urn:ietf:wg:oauth:2.0:oob:auto.

Последовательность шагов:

1. Начало аутентификации, путем отправки запроса на конечную точку /authorize/certificate по HTTPS с аутентификацией по сертификату.
2. Получение кода авторизации.
3. Получение AccessToken по коду авторизации.
4. Получение делегирующего AccessToken.

AccessToken, полученный на шаге 3, позволит Оператору получить Политику Сервиса Подписи.

Для выполнения действий от имени пользователя на Сервисе Подписи необходимо получить делегирующий AccessToken. Делегирующий AccessToken позволит Оператору выпустить сертификат пользователя, просмотреть список сертификатов и запросов пользователя и т.п.

Начало аутентификации

Конечная точка для аутентификации Оператора: /authorize/certificate

Параметры запроса:

• redirect_uri – зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращен запрошенный код авторизации). Допустимые значения данного параметра сохраняются в ЦИ на этапе регистрации клиента.
• response_type – в данном сценарии всегда должен иметь значение code.
• scope – области использования маркера. Должен содержать значение dss.
• resource – идентификатор Сервиса Подписи.

Примеры запросов

GET https://{{hostname}}/{{instanceName}}/oauth/authorize/certificate?client_id=testClient&response_type=code&scope=dss&redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto&resource=urn:cryptopro:dss:signserver:signserver
Host: host
Connection: Keep-Alive

Получение кода авторизации

В случае успешной аутентификации

• ответ сервера будет иметь статус HTTP 302
• В заголовке Location будет сожержаться адрес получения AccessToken.

Т.е. в примере используется специальное значение redirect_uri, то клиенту необходимо из заголовка Location извлечь значение параметра code. Значение параметра code будет использовано для получения AccessToken на следующем шаге.

Пример ответа

HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Location: urn:ietf:wg:oauth:2.0:oob:auto?code=65e4322a9751cf9ba43012692ce02ec1
Date: Fri, 07 Sep 2018 10:30:24 GMT
Content-Length: 0

Типовые ошибки

HTTP-код	Ошибка	Описание
400	invalid_client	OAuth-клиент не зарегистрирован или неверно указан ClientID
400	unauthorized_client	OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
400	invalid_request	Неверно сформирован параметр resource
500	An error has occurred	Проверяющая сторона с идентификатором resource не зарегистрирована.

Получение AccessToken

Для получения маркера доступа используется конечная точка oauth/token.

Параметры запроса:

• grant_type - тип разрешения, в данном сценарии равен authorization_code.
• code – код авторизации, полученный на предыдущем шаге.
• resource – идентификатор Сервиса Подписи.
• redirect_uri – зарегистрированный на Центре Идентификации адрес возврата.

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64(<client_id>:<secret>)

Пример запроса

POST https://{{hostname}}/{{instanceName}}/oauth/token HTTP/1.1
Authorization: Basic dGVzdENsaWVudDo=
Content-Type: application/x-www-form-urlencoded
Host: host
Content-Length: 180
Expect: 100-continue

grant_type=authorization_code&code=65e4322a9751cf9ba43012692ce02ec1&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&resource=urn%3Acryptopro%3Adss%3Asignserver%3Asignserver

В случае успешной аутентификации ответ будет содержать:

• access_token - AccessToken, выпущенный Центром Идентификации
• token_type - Тип токена
• expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Примечание

Данный access_token не дает право Оператору выполнять операции на Сервисе Подписи от имени пользователей. access_token может быть использован для получения Политики Сервиса Подписи.

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 2268
Content-Type: application/json; charset=utf-8
Expires: -1

{"access_token":"eyJ0eXAiOiJKV1Q ... LnS1sAunDSE1hh3A5n8W7lhPSM4z_VA","expires_in":300,"token_type":"Bearer"}

HTTP-код	Ошибка	Описание
400	invalid_client	OAuth-клиент не зарегистрирован или неверно указан ClientID
400	unauthorized_client	OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
400	invalid_request	Неверно сформирован параметр resource
400	invalid_grant	Невалидный код авторизации.
500	An error has occurred	Проверяющая сторона с идентификатором resource не зарегистрирована.

Получение делегирующего AccessToken

Для получения AccessToken для делегирования используется конечная точка oauth/token. Подробная информация по протоколу получения AccessToken для делегирования: OAuth 2.0 Token Exchange.

Параметры запроса:

• grant_type - тип разрешения, в данном сценарии равен urn:ietf:params:oauth:grant-type:token-exchange.
• resource – идентификатор Сервиса Подписи.
• actor_token - AccessToken, полученный на предыдущем шаге
• actor_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token – неподписанный JWT-токен, содержащий логин управляемого пользователя.

В декодированном виде subject_token имеет вид:

{
    "alg": "none",
    "typ": "JWT"
}.
{
    "unique_name": "mydss",
    "nbf": 1488312889,
    "exp": 1488316489,
    "iat": 1488312889
}
.

Пример кодирования JWT-токена можно посмотреть по ссылке.

Первая часть (до точки) называется header, вторая – payload. Для получения закодированного значения необходимо выполнить следующее преобразование:

Base64UrlEncode(Utf8GetBytes(header)) + “.” + Base64UrlEncode(Utf8GetBytes(payload)) + “.” 

Внимание!

Символ “.” в конце получившегося значения является обязательным.

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64(<client_id>:<secret>)

Пример запроса

POST https://{{hostname}}/{{instanceName}}/oauth/token HTTP/1.1
Authorization: Basic dGVzdENsaWVudDo=
Content-Type: application/x-www-form-urlencoded
Host: host
Content-Length: 2529
Expect: 100-continue

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange&actor_token=eyJ0eXAiOiJKV1QiLCJhbGc ... E1hh3A5n8W7lhPSM4z_VA&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt&subject_token=e30.eyJ1bmlxdWVfbmFtZSI6Im15ZHNzIn0.&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt&resource=urn%3Acryptopro%3Adss%3Asignserver%3Asignserver

В случае успешной аутентификации ответ будет содержать:

• access_token - делегирующий AccessToken, выпущенный Центром Идентификации
• token_type - Тип токена
• expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Пример ответа

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 2475
Content-Type: application/json; charset=utf-8
Expires: -1

{"access_token":"eyJ0eXAiOiJKV1QiL ... hOX-7aUneD_po8p5uD3nJGQ5VIHJHiwg4vA","expires_in":300,"token_type":"Bearer"}