Приложение. Описание веб сервиса Росреестра для приема заявлений и запросов в электронном виде

Приложение
к приказу Федеральной службы государственной
регистрации, кадастра и картографии
от 17 февраля 2017 г. N П/0074

Описание веб сервиса Росреестра
для приема заявлений и запросов в электронном виде

1. Описание методов

Веб-сервис предоставляет следующие методы:

- CreateRequest - создание заявления;

- GetEvent - предоставление информации о статусе заявления;

- LoadEventDetails - получение информации о результатах выполнения услуги;

- DeleteEvents - удаление событий, зарегистрированных под идентификаторами в переданной коллекции.

Сервис, находящийся в промышленной эксплуатации находится по адресу: https://portal.rosreestr.ru:4433/cxf/External?wsdl.

Для доступа к сервису необходимо иметь установленный контейнер с ключевой парой, с помощью которой устанавливается SSL соединение с сервером.

1.1 Метод createRequest

Метод предназначен для регистрации заявления (запроса) в информационной системе поставщика Росреестра (таблица 1).

Таблица 1

Параметр	Тип	Описание
region	IN	Регион, в который необходимо отправить заявление
okato	IN	ОКАТО
oktmo	IN	ОКТМО, необязательный
requestData	IN	Пакет заявления. Zip-файл
requestType	IN	Тип запроса. См. справочник dRequest_Type.xsd
requestNumber	OUT	Номер запроса
status	OUT	Статус операции. Тип OperationStatus

IN - входной параметр

OUT - выходной параметр

Описание типа OperationStatus приведено в таблице 2:

Таблица 2

Параметр	Тип	Описание
result	boolean	Результат выполнения
message	string	Необязательный. Описание, в случае если result==false

1.2 Метод getEvents

Получение статуса обработки заявления по запросу реализуется методом getEvents.

Описание метода приведено в таблице 3:

Таблица 3

Параметр	Тип	Описание
lastEventID	IN	Уникальный идентификатор последнего события, от которого вернется список, либо если необходимо получить все события - пустая строка - null
events	OUT	Коллекция структуры EventStruct
status	OUT	Статус операции. Типа OperationStatus

Описание структуры OperationStatus приведено в таблице 2.

Описание структуры EventStruct приведено в таблице 4:

Таблица 4

Параметр	Тип	Описание
eventID	string	Уникальный идентификатор события
eventType	string	Тип события - STATUS - OUTDOC - RECEIPT
eventDate	dateTime	Время записи события
requestNumber	string	Номер заявки, к которой относится событие

Разработанные компоненты предусматривают возможности:

- получения единичного статуса по заявлению (актуального на определенный момент времени);

- получения истории смены всех статусов с момента создания заявления.

В случае присвоения параметру lastEventID значения "null" или пустого значения возвращается весь список событий (статусов) по заявлению. В противном случае возвращаются данные по последнему статусу.

1.3 Метод loadEventDetails

Предоставление результатов исполнения услуги осуществляется вызовом метода loadEventDetails.

Описание метода приведено в таблице 5:

Таблица 5

Параметр	Тип	Описание
eventID	IN	Уникальный идентификатор события
detailsXML	OUT	Детальное описание события - Status.xsd - Receipt.xsd - Outdoc.xsd
binary	OUT	В случае событий - RECEIPT - OUTDOC Бинарный файл в base64. В случае события - STATUS будет null
status	OUT	Статус операции. Типа OperationStatus

1.4 Метод deleteEvents

Метод позволяет удалить события, зарегистрированные под идентификаторами в переданной коллекции. Является операцией типа InOnly.

Параметр	Тип	Описание
eventIDs	IN	Коллекция идентификаторов событий, которые надо удалить

2. Основные технические решения

2.1. Схема взаимодействия

Разработанные программные средства соответствуют общей архитектуре решения по взаимодействию с внешними информационными системами. Логическая схема взаимодействия компонент представлена на Рисунке 1.

Рисунок 1

1. Клиент обращается для формирования выписки из Единого государственного реестра недвижимости, предоставления документов на государственную регистрацию прав и (или) кадастровый учет. Происходит двусторонняя аутентификация.

2. Формируется запрос при помощи метода CreateRequest.

3. Каждому заявлению присваивается идентификационный номер, который сообщается клиенту (в XML-запросе соответствует строка <Number>).

В случае сбоя в ответ на вызов метода поступит сообщение об ошибке.

4. Запрос клиента проходит форматно-логический контроль (ФЛК).

Если форматно-логический контроль не пройден, система формирует сообщение об ошибке с указанием причины ее возникновения. Результат прохождения ФЛК клиент может узнать, вызвав метод getEvents, либо loadEventDetails.

5. Если клиент имеет право на безвозмездное получение услуги, то заявление переходит в статус "В работе", минуя шаг оплаты.

6. Если клиент получает услугу на платной основе, то заявление переходит в статус "Ожидает оплаты". Формируется уникальный код платежа. Данный код содержится в текстовом комментарии к статусу "Ожидает оплаты" и может быть получен вызовом методов getEvents либо loadEventDetails.

Информация о совершении платежа поступает в Росреестр автоматически. После получения подтверждения платежа заявление переходит в статус "В работе".

7. Сформированный ответ на заявление клиент может получить при помощи метода предоставления результатов услуг (метод LoadEventDetails).

2.2. Обеспечение двусторонней аутентификации

При взаимодействии ИС Росреестра с внешними ИС посредством веб-сервисов применяется двусторонняя аутентификация на основе сертификатов, соответствующих ГОСТ. Для получения ключей, предназначенных для взаимодействия в продуктивной среде, необходимо обратиться в один из доверенных удостоверяющих центров Росреестра, с перечнем доверенных УЦ можно ознакомиться на портале Росреестра по ссылке https://rosreestr.ru/site/fiz/programmnoe-obespechenie/perechen-udostover yayushchikh-tsentrov-ispolnivshikh-trebovaniya-rasporyazheniya-rosreestra -ot-27-03/?sphrase_id=1000714

Для реализации данного функционала применяется системное ПО Trusted TLS. Trusted TLS позволяет использовать российские стандарты криптографической защиты информации. Trusted TLS предназначен для построения систем, использующих сертифицированные ФСБ России СКЗИ, в прикладной системе, где есть необходимость в создании защищенного соединения между клиентом и сервером.

Для реализации двусторонней аутентификации на базе сертификатов, соответствующих ГОСТ, в системе предусмотрен следующий алгоритм:

1. Клиент запрашивает доступ к защищенному ресурсу, в ответ сервис отправляет клиенту свой сертификат.

2. Клиент проверяет полученный сертификат по следующим параметрам:

a) текущая дата находится между датами начала и окончания действия сертификата;

b) издатель сертификата находится в списке доверенных удостоверяющих центров клиента;

c) сертификат отсутствует в списках отозванных сертификатов.

3. При положительном результате выполнения проверок, описанных в шаге 2, клиент пересылает сервису свой сертификат, который проходит аналогичную проверку на стороне поставщика.

4. При негативном результате проверки клиентского сертификата доступ к сервису будет запрещен. В случае успешной проверки устанавливается защищенное соединение. Данные между клиентом и сервисом передаются в зашифрованном виде (данные от клиента шифруются приватным ключом клиента и открытым ключом сервиса, от сервиса - наоборот).

2.3. Требования к zip-архиву

Имя файла: req_<GUID_пакета>.zip

GUID_пакета имеет вид xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Состав:

- XML-файл с данными заявления (req_<GUID_заявления>.xml), расположенный в корне архива;

- файл подписи заявления (req_<GUID_заявления>.xml.sig);

- также может содержать файлы электронных документов (межевые планы, технические паспорта, сканы документов) и образы приложенных документов, которые могут находиться на любом уровне вложенности в архиве, в таком случае пути должны быть прописаны в XML-файле заявления (req_<GUID_заявления>.xml);

- для формирования корректного пакета заявления следует руководствоваться соответствующей типу запрашиваемой услуги XSD-схемой.

2.4. Требования к включению ЭП файлов в zip-архив

Все файлы, входящие в zip-архив, подписываются ЭП.

ЭП файла формируется по правилам, указанным в п. 2.5.

ЭП включаются в zip-архив в виде отдельных файлов, каждый из которых располагается в том же каталоге/подкаталоге, что и подписываемый файл, причем имя файла подписи получается из имени подписываемого файла с расширением, добавлением расширения .sig.

2.5. Требования к формированию ЭП файла

ЭП передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt).

Для сохранения в файл используется DER-кодировка. ЭП передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. ЭП должна включать в себя сертификат и не должна включать подписанное содержимое.

Контейнер PKCS #7 должен быть совместим с контейнером, формируемым криптопровайдером КриптоПро CSP версии 3.6 (http://www.cryptopro.ru/CryptoPro/documentation).