Интеграция со СМЭВ 3.хх — весь спектр услуг по подключению и работе со СМЭВ

«Госуслуги» прочно вошли в нашу жизнь как средство взаимодействия с органами власти. Больше не нужно стоять в очередях, чтобы заменить паспорт, оплатить налог или записаться на прием к врачу — достаточно внести личные данные и сделать пару кликов. Однако все эти операции включают в себя шаги и состояния, скрытые от пользователя за простыми записями и оповещениями.

В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

Управление имущественными и земельными отношениями

Назначение программного комплекса SAUMI 4.X

• Учет государственной и муниципальной собственности
• Повышение эффективности и качества управления земельно-имущественным комплексом
• Адаптация к требованиям регионального и местного законодательства 

• Ведение реестра имущества
• Ведение адресного реестра
• Ведение реестра контрагентов правоотношений
• Ведение реестра документов
• Ведение реестра правоотношений
• Учет финансовых обязательств
• Возможность размещения QR-кодов на генерируемых документах
• Подсистема поиска
• Формирование аналитических отчетов
• Поддержка нескольких базовых собственников
• Аудит действий пользователей
• Поддержка претензионно-исковой работы
• Соответствие стандарту бухучета для госсектора “Аренда”

Преимущества:

Оптимизация отчетности

Повышение эффективности работы с документами

Развитие электронного правительства

Повышение эффективности претензионно-исковой работы (ПИР)

Соответствие требованиям Федерального казначейства

Повышение удобства оплаты обязательств

Повышение позиции в рейтинге участников ГИС ГМП

Для кого:

Администрации субъектов Российской Федерации

Органы местного самоуправления муниципальных образований

Федеральные, региональные и муниципальные учреждения

Государственные компании

Владельцы компаний, управляющие коммерческой недвижимостью

Ресурсоснабжающие и транспортные организации

Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.

В настоящее время СМЭВ продолжает расширять свои возможности и вовлекать все большее количество участников взаимодействия.

Что оказалось как нельзя кстати, в том числе для коммерческих организаций, в частности банков, которые все больше стремятся перевести свои услуги в цифру и сериализовать процессы.

В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.

Здравствуйте!

Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где

• опубликована вся документация и методические указания,
• есть раздел с часто задаваемыми вопросами,
• можно скачать актуальную версию библиотек клиента СМЭВ 3,
• предоставлены примеры полных конвертов сообщений с подписями,
• можно даже проверить онлайн свое сообщение или из примера на соответствие схемам сервиса СМЭВ и на предмет валидности его электронной подписи

Все верно, портал, безусловно, крайне полезный, и всеми его подсказками и инструментами можно и нужно пользоваться, но вот код на Java напишем свой.

По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.

Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.

В то же время заглянуть в открытый код клиента всегда полезно, а его наличие само по себе говорит о зрелости системы и высоком уровне поддержки.

Анализ исходных данных

Загружаем с портала СМЭВ 3:

• актуальную версию документа Методические рекомендации по работе с ЕСМЭВ версия 3.4.0.3
• примеры полных конвертов сообщений, отправляемых в СМЭВ 3

Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.

Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"> <S:Body> <ns2:SendRequestRequest xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"> <ns:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">	<ns:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns:MessageID><ns2:MessagePrimaryContent><ns1:BreachRequest xmlns:ns1="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" xmlns:ns2="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0" xmlns:ns3="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1" Id="PERSONAL_SIGNATURE"> <ns1:RequestedInformation> <ns2:RegPointNum>Т785ЕС57</ns2:RegPointNum> </ns1:RequestedInformation> <ns1:Governance> <ns2:Name>ГИБДД РФ</ns2:Name> <ns2:Code>GIBDD</ns2:Code> <ns2:OfficialPerson> <ns3:FamilyName>Загурский</ns3:FamilyName> <ns3:FirstName>Андрей</ns3:FirstName> <ns3:Patronymic>Петрович</ns3:Patronymic> </ns2:OfficialPerson></ns1:Governance> </ns1:BreachRequest> </ns2:MessagePrimaryContent>	<ns:TestMessage/></ns:SenderProvidedRequestData> <ns2:CallerInformationSystemSignature><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/><ds:Reference URI="#SIGNED_BY_CONSUMER"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J3746ks34pOcPGQpKzc0sz3n9+gjPtzZbSEEs4c3sTwbtfdaY7N/hxXzEIvXc+3ad9bc35Y8yBhZ/BYbloGt+Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIBcDCCAR2gAwIBAgIEHVmVKDAKBgYqhQMCAgMFADAtMRAwDgYDVQQLEwdTWVNURU0xMQwwCgYDVQQKEwNJUzIxCzAJBgNVBAYTAlJVMB4XDTE1MDUwNzEyMTUzMFoXDTE4MDUwNjEyMTUzMFowLTEQMA4GA1UECxMHU1lTVEVNMTEMMAoGA1UEChMDSVMyMQswCQYDVQQGEwJSVTBjMBwGBiqFAwICEzASBgcqhQMCAiMBBgcqhQMCAh4BA0MABEDoWGZlTUWD43G1N7TEm14+QyXrJWProrzoDoCJRem169q4bezFOUODcNooQJNg3PtAizkWeFcX4b93u8fpVy7RoyEwHzAdBgNVHQ4EFgQUaRG++MAcPZvK/E2vR1BBl5G7s5EwCgYGKoUDAgIDBQADQQCg25vA3RJL3kgcJhVOHA86vnkMAtZYr6HBPa7LpEo0HJrbBF0ygKk50app1lzPdZ5TtK2itfmNgTYiuQHX3+nE</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns2:CallerInformationSystemSignature> </ns2:SendRequestRequest> </S:Body>
</S:Envelope>

Дедуктивным методом выясняется что:

• больше не используется прием с выносом из содержимого тега Signature в Security заголовок элемента BinarySecurityToken с сертификатом открытого ключа проверки электронной подписи и ссылкой на него через SecurityTokenReference в теле самого Signature, как, например, в СМЭВ 2.4.6. Теперь сертификат должен находиться внутри Signature.
• второе и, по сути, самое существенное и важное изменение, оказывающее большое влияние на процесс подписи — это добавление новой проприетарной трансформации:

  <ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>

Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 3.

Каноникализация — процесс приведения данных, имеющих несколько возможных форм представления, к одному нормализованному стандартному виду.

Перед тем как посчитать хэш подписываемого атрибута в XML-конверте и подписать, необходимо выполнить его конвертацию в заданный правилами СМЭВ 3 вид.

В поисках описания трансформации urn://smev-gov-ru/xmldsig/transform открываем Методические рекомендации 3.4.0.3

Знакомимся с пунктом 4.4.2.1 Правила формирования электронной подписи сообщений

Формат подписи XMLDSig detached (https://www.w3.org/TR/xmldsig-core/)

Трансформация, дополнительно к канонизации urn://smev-gov-ru/xmldsig/transform

Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

Пункт Методических указаний 12.4. ПРИЛОЖЕНИЕ 4: ОБРАЗЦОВАЯ РЕАЛИЗАЦИЯ ТРАНСФОРМАЦИИ URN://SMEV-GOV-RU/XMLDSIG/TRANSFORM
содержит Java класс SmevTransformSpi.java, реализующий алгоритм трансформации «urn://smev-gov-ru/xmldsig/transform», наследник org.apache.xml.security.transforms.TransformSpi из библиотеки Apache Santuario.

Таким образом, чтобы обеспечить каноникализацию подписываемого конверта СМЭВ 3, можно использовать в своем коде этот класс трансформации.

Единственным условием и ограничением в этом случае будет, что для обработки XML-документа при формировании подписи или ее проверки нужно использовать именно org.apache.xml.security.signature.XMLSignature из проекта Apache Santuario.

Задействовать инструменты из пакетов javax.xml.crypto.dsig или ru.CryptoPro.JCPxml.xmldsig просто так уже не получится.

Подготовка к подписи по правилам СМЭВ 3

Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.

В библиотеке xmlsec-1.5.0.jar в файле \org\apache\xml\security\resource\config.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.

Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.

По старинке это делалось так:

//APACHE-SANTUARIO INIT WITH CryptoPro JCP System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml"); org.apache.xml.security.Init.init(); String cfile1 = System.getProperty("org.apache.xml.security.resource.config"); LOGGER.log(Level.INFO, "Init class URL: " + org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation()); LOGGER.log(Level.INFO, cfile1);

В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:

ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();

Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:

 try { Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName()); santuarioIgnoreLineBreaks(true); LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized"); } catch (AlgorithmAlreadyRegisteredException e) { LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: " + e.getMessage()); } 

Заодно сразу выполняем требование из Методических указаний:

Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

santuarioIgnoreLineBreaks(true); private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";
/** * Apache Santuario privileged switch IgnoreLineBreaks property * * @param mode */ private void santuarioIgnoreLineBreaks(Boolean mode) { try { Boolean currMode = mode; AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() { public Boolean run() throws Exception { Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD); f.setAccessible(true); f.set(null, currMode); return false; } }); } catch (Exception e) { LOGGER.warning("santuarioIgnoreLineBreaks " + ExceptionUtils.getFullStackTrace(e)); } }

Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.

Просто через настройку системного свойства:

System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");

не работает.

Через настройку опции JVM:

-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true

работает.

Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».

private static boolean ignoreLineBreaks = AccessController.doPrivileged(new PrivilegedAction<Boolean>() { public Boolean run() { return Boolean.valueOf(Boolean.getBoolean ("org.apache.xml.security.ignoreLineBreaks")); } }).booleanValue();
public static boolean ignoreLineBreaks() { return ignoreLineBreaks; }

Такая реализация приводит к невозможности гибко настроить в одном Java процессе для части методов игнорировать перевод строк, а для другой части не игнорировать.

Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.

С этим свойством, конечно, возникает вопрос к Apache Santuario:

Подпись сообщений СМЭВ 3

Для подписи документов СМЭВ 3 все готово.

Код подписания выглядит следующим образом:

private static final String XMLDSIG_MORE_GOSTR34102001_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"; private static final String XMLDSIG_MORE_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr3411"; private static final String CANONICALIZATION_METHOD = "http://www.w3.org/2001/10/xml-exc-c14n#"; private static final String DS_SIGNATURE = "//ds:Signature"; private static final String SIG_ID = "sigID"; private static final String COULD_NOT_FIND_XML_ELEMENT_NAME = "ERROR! Could not find xmlElementName = "; private static final String GRID = "#"; private static final String XML_SIGNATURE_ERROR = "xmlDSignature ERROR: ";
try { // инициализация объекта чтения XML-документа DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); // установка флага, определяющего игнорирование пробелов в // содержимом элементов при обработке XML-документа dbf.setIgnoringElementContentWhitespace(true); // установка флага, определяющего преобразование узлов CDATA в // текстовые узлы при обработке XML-документа dbf.setCoalescing(true); // установка флага, определяющего поддержку пространств имен при // обработке XML-документа dbf.setNamespaceAware(true);
// загрузка содержимого подписываемого документа на основе // установленных флагами правил из массива байтов data DocumentBuilder documentBuilder = dbf.newDocumentBuilder(); Document doc = documentBuilder.parse(new ByteArrayInputStream(data)); /* * Добавление узла подписи <ds:Signature> в загруженный XML-документ */ // алгоритм подписи (ГОСТ Р 34.10-2001) final String signMethod = XMLDSIG_MORE_GOSTR34102001_GOSTR3411; // алгоритм хеширования, используемый при подписи (ГОСТ Р 34.11-94) final String digestMethod = XMLDSIG_MORE_GOSTR3411; final String canonicalizationMethod = CANONICALIZATION_METHOD; String[][] filters = {{XPath2FilterContainer.SUBTRACT, DS_SIGNATURE}}; String sigId = SIG_ID; // инициализация объекта формирования ЭЦП в соответствии с // алгоритмом ГОСТ Р 34.10-2001 XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod); // определение идентификатора первого узла подписи sig.setId(sigId); // получение корневого узла XML-документа Element anElement = null; if (xmlElementName == null) { anElement = doc.getDocumentElement(); } else { NodeList nodeList = doc.getElementsByTagName(xmlElementName); anElement = (Element) nodeList.item(0); } // = doc.getElementById("#AppData"); // добавление в корневой узел XML-документа узла подписи if (anElement != null) { anElement.appendChild(sig.getElement()); } else { throw new SignatureProcessorException(COULD_NOT_FIND_XML_ELEMENT_NAME + xmlElementName); } /* * Определение правил работы с XML-документом и добавление в узел подписи этих * правил */ // создание узла преобразований <ds:Transforms> обрабатываемого // XML-документа Transforms transforms = new Transforms(doc); // добавление в узел преобразований правил работы с документом // transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE); transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS); transforms.addTransform(SmevTransformSpi.ALGORITHM_URN); // добавление в узел подписи ссылок (узла <ds:Reference>), // определяющих правила работы с // XML-документом (обрабатывается текущий документ с заданными в // узле <ds:Transforms> правилами // и заданным алгоритмом хеширования) sig.addDocument(xmlElementID == null ? "" : GRID + xmlElementID, transforms, digestMethod); /* * Создание подписи всего содержимого XML-документа на основе закрытого ключа, * заданных правил и алгоритмов */ // создание внутри узла подписи узла <ds:KeyInfo> информации об // открытом ключе на основе // сертификата sig.addKeyInfo(x509Cert); // создание подписи XML-документа sig.sign(privateKey); // определение потока, в который осуществляется запись подписанного // XML-документа bais = new ByteArrayOutputStream(); // инициализация объекта копирования содержимого XML-документа в // поток TransformerFactory tf = TransformerFactory.newInstance(); // создание объекта копирования содержимого XML-документа в поток Transformer trans = tf.newTransformer(); // копирование содержимого XML-документа в поток trans.transform(new DOMSource(doc), new StreamResult(bais)); bais.close(); } catch (TransformationException e) { throw new SignatureProcessorException("TransformationException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (XMLSignatureException e) { throw new SignatureProcessorException("XMLSignatureException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (TransformerException e) { throw new SignatureProcessorException("TransformerException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (IOException e) { throw new SignatureProcessorException("IOException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (XMLSecurityException e) { throw new SignatureProcessorException("XMLSecurityException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (SAXException e) { throw new SignatureProcessorException("SAXException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (ParserConfigurationException e) { throw new SignatureProcessorException( "ParserConfigurationException " + XML_SIGNATURE_ERROR + e.getMessage()); } return bais.toByteArray();

Основными параметрами здесь являются:

byte[] data, // XML сообщение в виде массива байтов
String xmlElementName, // имя элемента в XML вместе с префиксом, в который следует добавить подпись, для СМЭВ-3 в общем случае "ns2:CallerInformationSystemSignature"
String xmlElementID // ID элемента в XML (если присутствует) вместе с префиксом, на который следует поставить подпись, для СМЭВ-3 в общем случае "SIGNED_BY_CONSUMER"
X509Certificate certificate // сертификат открытого ключа проверки подписи
PrivateKey privateKey // закрытый ключ подписи

Проверка подписи сообщения СМЭВ 3

Код проверки подписи выглядит следующим образом:

private static final QName QNAME_SIGNATURE = new QName("http://www.w3.org/2000/09/xmldsig#", "Signature", "ds"); private static final String SIGNATURE_NOT_FOUND = "Signature not found!"; private static final String SIGNATURE_NOT_VALID = "Signature not valid"; private static final String SMEV_SIGNATURE_PASSED_CORE_VALIDATION = "SmevSignature passed core validation"; private static final String VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION = "Verify signature on XML IOException: "; private static final String VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION = "Verify signature on XML ParserConfigurationException: "; private static final String VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION = "Verify signature on XML SAXException: "; private static final String VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION = "Verify signature on XML XMLSignatureException: "; private static final String VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION = "Verify signature on XML XMLSecurityException: "; private static final String ID = "Id"; boolean coreValidity = true; try { DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance(); bf.setNamespaceAware(true); DocumentBuilder b = bf.newDocumentBuilder(); Document doc = b.parse(new InputSource(new ByteArrayInputStream(signedXmlData))); NodeList sigs = doc.getElementsByTagNameNS(QNAME_SIGNATURE.getNamespaceURI(), QNAME_SIGNATURE.getLocalPart()); org.apache.xml.security.signature.XMLSignature sig = null; sigSearch: { for (int i = 0; i < sigs.getLength(); i++) { Element sigElement = (Element) sigs.item(i); String sigId = sigElement.getAttribute(ID); if (sigId != null) { sig = new org.apache.xml.security.signature.XMLSignature(sigElement, ""); break sigSearch; } } throw new XMLSignatureVerificationException(SIGNATURE_NOT_FOUND); } org.apache.xml.security.keys.KeyInfo ki = (org.apache.xml.security.keys.KeyInfo) sig.getKeyInfo(); X509Certificate certificate = ki.getX509Certificate(); if (!sig.checkSignatureValue(certificate.getPublicKey())) { coreValidity = false; LOGGER.log(Level.INFO, SIGNATURE_NOT_VALID); } else { LOGGER.log(Level.INFO, String.format(SMEV_SIGNATURE_PASSED_CORE_VALIDATION)); } } catch (IOException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (ParserConfigurationException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (SAXException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (org.apache.xml.security.signature.XMLSignatureException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (XMLSecurityException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION + ExceptionUtils.getStackTrace(e)); } return coreValidity;

Проблемы. Хэш не совпадает

Внимание!

Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.

Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как

ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП

Почему

<ds:DigestValue>e76oVeYGapFDE+PV6glsj0XDjLHydLMd0cSkFPY8fWk=</ds:DigestValue>

не совпадал с оригинальным примером:

<ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo==</ds:DigestValue>

Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8); 

для параллельного анализа всех этапов трансформации.

Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns4:Name>ГИБДД РФ</ns4:Name><ns4:Code>GIBDD</ns4:Code><ns4:OfficialPerson><ns5:FamilyName xmlns:ns5="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns5:FamilyName><ns5:FirstName>Андрей</ns5:FirstName><ns5:Patronymic>Петрович</ns5:Patronymic></ns4:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

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

Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.

Старая версия класса трансформации выдала следующий нормализованный документ:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns5:Name xmlns:ns5="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">ГИБДД РФ</ns5:Name><ns6:Code xmlns:ns6="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">GIBDD</ns6:Code><ns7:OfficialPerson xmlns:ns7="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"><ns8:FamilyName xmlns:ns8="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns8:FamilyName><ns9:FirstName xmlns:ns9="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Андрей</ns9:FirstName><ns10:Patronymic xmlns:ns10="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Петрович</ns10:Patronymic></ns7:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

С ним хэш стал совпадать, а подпись успешно проходить валидацию.

Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:

if (logger.isDebugEnabled()) { debugStream = new DebugOutputStream(argDst); dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8); } else { dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8); }

Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:

Отсутствует строка:

prefixMappingStack.pop();

, которая удаляет первый объект из стека с префиксами

 Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();

, что приводило к неверной работе SmevTransformSpi.

Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.

Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3

Результаты

Подписание конвертов СМЭВ 3 выполняется успешно.

Сообщения проходят проверку на портале Электронного правительства Госуслуги

И в собственном приложении:

Наши принципы

Используем готовые решения

Мы опираемся на свой собственный опыт, используем проверенные наработки и свободно
распространяемые
решения. Вы не платите за разработку нового ПО с нуля.

Масштабируемость решения

Подберем индивидуальное решение под ваши задачи и инфраструктуру.Мы используем как
монолитные приложения, так и микросервисный подход в реализации решений.

Гарантируем результат

Консультируем и помогаем до достижения результата в ходе всех необходимых
интеграционных тестов и подготовки документации на выход в промышленную эксплуатацию СМЭВ 3.xx.

Установка нового СМЭВ-адаптера Минцифры России

Проведение консультаций и тонкая настройка нового микросервисного интеграционного узла адаптера (ИУА) от Министерства цифрового развития, связи и массовых коммуникаций для работы со СМЭВ 3.хх:

1. Подготовка сайзинга системы на основе выявленных потребностей по работе со СМЭВ
2. Установка УИА на выделенных виртуальных машинах
3. Тонкая настройка УИА до прогнозируемых показателей быстродействия
4. Постановка на мониторинг компоненты
5. Проведение консультаций по работе ИУА в промышленной эксплуатации

Подключение к виду сведения СМЭВ 3.хх

1. Проведение консультации по закупке оборудования
2. Подготовка запроса на подключение к виду сведения
3. Установка Интеграционного узла Адаптера (ИУА) для работы со СМЭВ 3.хх
4. Проведение тестирования на тестовом контуре СМЭВ 3.хх и формирование отчета о тестировании для подключения к промышленному стенду
5. Организация подключения к виду сведения на промышленном стенде СМЭВ 3.хх

Регистрация вида сведений в СМЭВ 3.хх

1. Проведение консультации по закупке оборудования
2. Подготовка пакета документов на регистрацию вида сведений в тестовом контуре СМЭВ 3.хх
3. Установка Интеграционного Узла Адаптера (ИУА) по работе со СМЭВ 3.хх
4. Проведение тестирования на тестовом контуре СМЭВ 3.хх и подготовка пакета документов на регистрацию вида сведений в промышленном контуре
5. Вывод вида сведений в промышленный контур СМЭВ 3.хх

Подключение вашей организации к СМЭВ 3.xx

1. Подготовка сайзинга системы на основе выявленных потребностей по работе со СМЭВ
2. Проведение консультации по закупке оборудования
3. Регистрация организации на подключение / регистрации вида сведений
4. Проведение предварительного анализа доработок внутренних систем для работы со СМЭВ 3.хх

Анализ и доработка вашей системы для работы со СМЭВ 3.хх

1. Предварительный анализ доработок ваших систем для работы со СМЭВ 3.хх
2. Подготовка дорожной карты модернизации внутренних систем
3. Предоставление команды разработки для реализации доработок в составе:
   • Руководитель проекта
   • Системный аналитик
   • Back-end разработчики (java, .net)
   • Тестировщики
   • Cистемные администраторы

• Установка ИУА
• Подключение к ВС
• Регистрация ВС
• Подключение к СМЭВ
• анализ
  ИТ-ландшафта

Мы знаем, что предлагаем

Наша команда консультантов участвует более 6 лет в разработке решений СМЭВ 2, СМЭВ 3.хх
и сейчас занимается поддержкой решения СМЭВ 3.хх в промышленном контуре.

Мы
разрабатывали адаптеры и подключали системы как к СМЭВ 2,
так и к СМЭВ 3.хх более десяти федеральных и региональных органов исполнительной
власти.

Адаптер Минцифры — наша компетенция

Наша команда участвовала в разработке интеграционного узла адаптера (ИУА) — нового
СМЭВ-адаптера рекомендованного Минцифрой России к установке в качестве подрядчика.

Мы пониманием как работает СМЭВ-адаптер и проведем консультацию по лучшей практике интеграции информационных
систем со СМЭВ с использованием официального адаптера от Минцифры.

СО СМЭВ 2. хх и 3

лет опыта работы

В добрых отношениях

клиентов с нами

В организациях

решений внедрены

Шаг первый — Подписание договора

Наша команда подготовила шаблоны договоров о продаже лицензии с передачей дистрибутива или исходного кода, а также шаблон договора о предоставлении услуг сопровождения на 12 месяцев:

• Выбирайте для себя оптимальные условия, скачивайте подготовленный нами
  договор и заполняйте реквизиты своей организации.
• Направляйте подписанный скан договора со своей стороны и заполненный исходный
  docx на электронную почту smev3@digitalleague.ru.
• Ожидайте, в течение 1 рабочего дня договор будет подписан с нашей стороны, после чего мы уведомим контактное лицо по телефону или электронной почте.

Шаг второй — Поставка продукта и его установка

После подписания и получения договоров обеими сторонами, наши специалисты предоставят вам доступ к GIT для скачивания исходного кода продукта, либо передадут ссылку на его дистрибутив.
Следуйте инструкции администратора продукта, а в случае возникновении сложностей — обращайтесь к нам за помощью.

Шаг третий — Сопровождение продукта

Если вы заранее оформили услугу сопровождения продукта или
в процессе эксплуатация поняли о ее необходимости — мы всегда поможем вам разобраться с
проблемами, которые у вас возникают при работе. Для этого мы предоставляем доступ
к нашей системе управления инцидентами и в рамках согласованного SLA обрабатываем ваши
вопросы.

Готовы рассмотреть
продукт?

Часто возникающие
вопросы

Для чего используется это приложение?

Приложение предоставляет унифицированный интерфейс (REST API) для работы со СМЭВ 3.хх. Модуль инкапсулирует базовые операции по работе с сообщениями в СМЭВ: передача, прием обращений.

Какой стек технологии?

Используется Java, Spring Boot, MongoDB\PostgreSQL\Oracle DB, Docker.

Минимальные требования к инфраструктуре

Минимальными требованиями к развертыванию компоненты является 1 CPU, 2GB RAM, 5GB HDD.

Для чего может понадобиться поддержка по продукту?

Мы неограничиваемся работами по продаже готового продукта и готовы произвести его доработку под ваши специфические требования, а также провести консультирование по встраиванию приложения в ваш IT ландшафт.

Наша команда

Система исполнения регламентов

Назначение СИР — автоматизация процессов предоставления государственных и муниципальных услуг гражданам и организациям (Заявителям) по заявлениям, поступающим с Портала Государственных услуг, а также, при личном обращении Заявителей в РОИВ, ОМСУ и в подведомственные им учреждения; регламентированное взаимодействие между различными РОИВ и ОМСУ и иными информационными системами, с использованием системы межведомственного электронного взаимодействия (СМЭВ).

Описание систем исполнения регламентов

Руководство пользователя СИР 3.0

Состав процедур, необходимых для обеспечения возможности работать в СИР и последовательность их выполнения описаны в документе «Технологическая карта процесса подготовки и предоставления услуг РОИВ и ОМСУ»

Порядок действий пользователей СИР по настройке рабочих мест с переходом на аутентификацию через ЕСИА

1. Настройка ПК пользователя.

1. Проверить настройку ПК в соответствии с Инструкцией по настройке рабочего места АРМ
2. Дополнить настройку ПК, согласно инструкции Техническая настройка для перехода в СИР на аутентификацию через ЕСИА
3. В браузере Internet Explorer добавить в «надежные сайты» адрес https://esia.gosuslugi.ru

2. Настройка Пользователя

1. Зарегистрировать себя, как физическое лицо на сайте ЕСИА https://esia.gosuslugi.ru, согласно Инструкции по переходу на аутентификацию с использованием ЕСИА. Результатом регистрации должно быть получение подтвержденной учетной записи физ. лица в ЕСИА
2. Уполномоченный сотрудник ведомства, к которому относится Пользователь (руководитель или администратор), должен выполнить в ЕСИА процедуру присоединения сотрудника к органу власти (ведомству) — см. Инструкции по переходу на аутентификацию с использованием ЕСИА
3. Направить заявку на sd@egov66.ru на создание учетной записи пользователя в СИР по своему СНИЛС, либо выпуск сертификата доступа к системе, в том случае, если ранее Пользователь не работал в СИР. Если Пользователь имел сертификат доступа к СИР, то проверить срок его действия. Если закончился, то направить заявку на sd@egov66.ru на продление этого сертификата (чтобы сохранить все настройки пользователя в СИР).
4. Получив ответ от техподдержки о создании учетной записи пользователя СИР, либо сертификат доступа к системе, новый Пользователь должен направить заявку на sd@egov66.ru на настройку его СНИЛС, либо сертификата, на какие-то виды настроек: для работы с МФЦ, для настройки на АРМ МВ, для настройки на тиражируемые услуги ЛАНИТ и АТК, на АРМ–Поставщика и др.
5. Направить на sd@egov66.ru Заявку на изменение пользователей СНИЛС

3. Порядок входа Пользователя в СИР по окончании настроeк

1. Открыть браузер Mozilla Firefox, и очистить в нем КЭШ и КУКи
2. Ввести в адресную ссылку https://66.sir.egov.local/tp-manager/
3. Подтвердить выбор своего сертификата, если система предложит — выполнится переход на ЕСИА автоматически
4. Подтвердить себя в ЕСИА. Подтвердить выбор своего сертификата, если система предложит. Выполнится переход на СИР автоматически.

Главная

Что такое ГУЦ?

Информационная система головного удостоверяющего центра

Назначение системы:

• Создание и контроль актуальности сертификатов электронной подписи аккредитованных удостоверяющих центров
• Выполнение проверок сертификатов электронной подписи

Подробная информация

Ссылка на систему: e-trust.gosuslugi.ru

Как подключиться к СМЭВ?

В соответствии с Регламентом СМЭВ 2.х и Регламентом СМЭВ 3.х к СМЭВ могут быть подключены только следующие категории Участников: ОИВ, ОМСУ, УЦ, ЗАГС, МФЦ, БКИ, Кредитные организации, Брокеры, Управляющие, Депозитарии, Управляющие компаний специализированных обществ, ПА, БПА. С критериями определения Участников можно ознакомиться в документе, опубликованном на Технологическом портале СМЭВ: http://smev.gosuslugi.ru/portal/api/files/get/194774.

Для подключения к СМЭВ необходимо направить заявку на присоединение к Регламенту СМЭВ. Оригинал заявки направляется в Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации (125375, г. Москва, ул. Тверская, д. 7) с сопроводительным письмом на бланке организации. Дополнительно посредством личного кабинета Ситуационного центра необходимо создать запрос на подключение к СМЭВ приложив скан-копию направленной заявки на присоединение.

Примечание:

Территориальные органы/структурные подразделения не являются Участниками взаимодействия. Взаимодействие со СМЭВ структурных подразделений осуществляется через головную организацию. Взаимодействие внутри организации производится по внутренним каналам Участника взаимодействия.

На основании чего требуется электронный адрес smev@<домен организации>?

В соответствии с п. 5.1 Регламента СМЭВ 2.х и п. 9.1 Регламента СМЭВ 3.х:

Участник должен создать выделенный электронный почтовый ящик, предназначенный для переписки по вопросам СМЭВ. Адрес почтового ящика должен быть составлен следующим образом: smev@<домен>, где <домен> это домен, владельцем которого является Участник.

Запрос по электронной почте должен отправляться только с выделенного почтового ящика, предназначенного для переписки по вопросам СМЭВ, вида smev@<домен>, в противном случае он не будет рассмотрен.

Дополнительно напоминаем о том, что основным способом направления обращения является личный кабинет ситуационного центра. Для входа необходимо перейти на сайт: https://sc.minsvyaz.ru и нажать «Войти». На открывшейся форме авторизации в ЕСИА, ввести свой телефон (СНИЛС, e-mail) и пароль и, войдя в личный кабинет ЕСИА, на странице «Выбор роли» нажать на строку с названием Вашей организации.

Электронная почта является резервным способом направления обращения, который используется в случае недоступности https://sc.minsvyaz.ru.

Почему для подключения функционала регламентации доступа по электронной подписи информационной системы (ЭП-ОВ) на отдельном сервисе Поставщика, зарегистрированном в СМЭВ, необходима перерегистрация сервиса?

В СМЭВ не поддерживается режим, при котором для электронного сервиса Поставщика, зарегистрированного в СМЭВ, для одних потребителей применяются механизмы регламентации доступа по электронной подписи информационной системы (ЭП-ОВ), а для других – нет. В связи с этим, в случае необходимости настройки функционала регламентации доступа по электронной подписи информационной системы (ЭП-ОВ), существующий сервис Поставщика оставляют в эксплуатации до его отключения, одновременно инициируя перерегистрацию сервиса на основании обновленных Поставщиком руководства пользователя электронного сервиса и паспорта электронного сервиса. При перерегистрации в СМЭВ электронному сервису присваивается новый идентификатор (SID). Новый идентификатор сервиса сообщается Поставщику, и информация о версии сервиса с подключенным функционалом регламентации доступа по электронной подписи информационной системы (ЭП-ОВ) публикуется на технологическом портале СМЭВ.

После перерегистрации сервиса с подключенным функционалом регламентации доступа по электронной подписи, Оператор СМЭВ и Поставщик должны обеспечивать доступность ранее зарегистрированной версии сервиса Поставщика до тех пор, пока все Потребители сервиса не подтвердят готовность взаимодействовать с сервисом Поставщика по новому адресу в СМЭВ. Оператор СМЭВ по согласованию с Участниками может инициировать деактивацию старой версии сервиса без подключенного функционала регламентации доступа по электронной подписи в согласованные со сторонами сроки.

Как следует предоставлять контрольные примеры для электронных сервисов, содержащие электронную подпись?

В связи с тем, что при редактировании документа значение электронной подписи, вычисленной на основе сообщения при отправке, может быть легко изменено, в дополнение к тексту контрольных примеров, содержащихся в руководстве пользователя электронных сервисов, Поставщик должен предоставить файлы контрольных примеров в виде отдельных файлов. Для удобства, документы по отдельному электронному сервису необходимо предоставлять в едином zip-архиве, содержащем:

• Паспорт электронного сервиса;

• Руководство пользователя электронного сервиса;

• Контрольные примеры в виде отдельных файлов (электронные сообщения-примеры должны содержать электронную подпись ЭП-ОВ);

• ЭП информационной системы, используемой для подписания электронных сообщений, передаваемых сервисом в ответ на поступающие запросы других Участников информационного взаимодействия.

Как правильно оформить заявку на доступ к электронному сервису?

Один из этапов получения доступа к электронному сервису Поставщика в СМЭВ является оформление заявки на предоставление доступа к электронному сервису (Актуальную форму заявки можно найти на http://smev.gosuslugi.ru/portal/). Заявка должна включать сведения:

1. Наименование Участника информационного взаимодействия в СМЭВ, ОГРН – Потребителя информации, запрашивающего доступ;

2. Наименование и мнемонику информационной системы Потребителя, интерфейсом которой является электронный сервис, который будет обращаться к запрашиваемому сервису Поставщика. Мнемоника ИС – это буквенно-цифровой код информационной системы Участника информационного взаимодействия, который присваивается ИС в процессе ее регистрации в СМЭВ;

3. Наименование Поставщика информации в СМЭВ – Поставщика электронного сервиса, к сервису которого запрашивается доступ;

4. Реквизиты нормативных правовых актов, с указанием конкретных пунктов (частей, статей), подтверждающих основание получения доступа к электронному сервису (федеральные законы, постановления Правительства Российской Федерации, приказы Участника информационного взаимодействия об утверждении административных регламентов, соглашения об информационном обмене, иные правовые акты, предусматривающие информационное взаимодействие);

5. Наименование электронного сервиса с указанием идентификатора сервиса в СМЭВ (SID….);

6. Таблицу с указанным уровнем доступа к электронному сервису (полный уровень доступа ко всем операциям электронного сервиса или доступ к конкретным операциям электронного сервиса, перечисленным в таблице);

7. Подпись уполномоченного лица Потребителя, заверенную соответствующей гербовой печатью.

Технологические работы

В связи с проведением технологических работ возможны перерывы с доступом к
Ситуационному Центру в период с 23:00 14.07.2022 по 05:00 15.07.2022
(UTC/GMT+3).

14 Июль 2022

Технологические работы

В связи с проведением технологических работ возможны перерывы с доступом к
Ситуационному Центру в период с 23:00 05.07.2022 по 05:00 06.07.2022
(UTC/GMT+3).

05 Июль 2022

Система межведомственного электронного взаимодействия

C 1 июня 2022 года получение доступа к ВС с фиксированным и табличным типами маршрутизации планируется перенести из Ситуационного центра в Личный кабинет Участника взаимодействия – ЛК УВ. Возможность подачи заявки в СЦ будет заблокирована.

С подробной информацией о выполнении указанных процедур можно ознакомиться в п. 5.4.3, 5.4.4 Руководства пользователя ЛК УВ.

Обращаем внимание, что процедура получения доступа к ВС с прочими типами маршрутизации остается прежней – через Ситуационный центр.

C 22 июня 2021 года процедура Плановая/внеплановая замена сертификата в СМЭВ 3 перенесена из Ситуационного центра в Личный кабинет Участника взаимодействия – ЛК УВ

Подробная информация об ЛК УВ доступна на главной странице Технологического портала СМЭВ 3

Техническая поддержка регионального сегмента инфраструктуры электронного правительства осуществляется Екатеринбургским филиалом ПАО «Ростелеком»

Контакты центра поддержки пользователей:

Адрес электронной почты: sir@gosuslugi.ru

Телефон: 8-800-200-95-83.

Краткая характеристика Системы межведомственного взаимодействия СМЭВ

Инструкция по регистрации информационных систем в системе межведомственного электронного взаимодействия версии 2. 0 и версии 3

Приобрести усиленную квалифицированную электронную подпись органа власти в аккредитованном удостоверяющем центре. Перечень аккредитованных удостоверяющих центров доступен на сайте Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации по ссылке.

СМЭВ 2:

1. Направить на адрес Ситуационного центра Министерства связи и массовых коммуникаций России sd@sc.minsvyaz.ru заявку на регистрацию информационной системы ведомства в СМЭВ 2 и присвоение мнемоники. Формирование заявки осуществляется по правилам, описанным в документе «Таблица с типизацией запросов в СМЭВ» (графа «Запрос на регистрацию в СМЭВ информационной системы»). В заявку вложить zip-архив с двумя файлами: паспорта информационной системы (далее — ИС) (форма паспорта доступна по ссылке is_passport_template.xls) и сертификата ключа электронной подписи органа власти (файл с расширением .cer в формате BASE64);
2. Удостовериться в получении ответа от Ситуационного центра о завершении выполнения заявки и присвоении мнемоники ИС в СМЭВ 2.

СМЭВ 3:

1. Направить на адрес Ситуационного центра Министерства связи и массовых коммуникаций России sd@sc.minsvyaz.ru заявку на регистрацию ИС ведомства в СМЭВ 3 и присвоение мнемоники. Актуальная форма заявки доступна по ссылке smev3.gosuslugi.ru/portal/. К заявке в zip-архиве приложить сертификат (в формате BASE64) ключа электронной подписи;
2. Удостовериться в получении ответа от Ситуационного центра о завершении выполнения заявки и присвоении мнемоники ИС в СМЭВ 3.

Горячие темы

Взаимодействие с ГИС ГМП
Может осуществляться несколькими участниками с разными уникальными регистрационными номерами участника взаимодействия; позволяет поддерживать форматы ГИС ГМП 2.Х, электронные подписи с шифрованием по ГОСТ 34.10-2012; расширяет способы отправки начислений по обязательству; улучшает позиции в рейтинге взаимодействия субъектов РФ с ГИС ГМП

Программный модуль «Электронная отчетность 2.0» (web-версия)
Формирует оперативную отчетность через web-интерфейс. Через модуль подотчетная организация может просматривать и актуализировать сведения, отражать факты списания имущества, добавлять информацию о новом имуществе и др.

Поддержка СМЭВ 3
Переход на последнюю версию системы межведомственного электронного взаимодействия СМЭВ 3 упрощает коммуникацию между ведомствами и позволяет перевести уже существующие сервисы на новый формат.

Массовая генерация документов из HTML-шаблонов
Упрощает работу специалистам: позволяет создавать документы на основе шаблонов, поддерживать xml-выписки Федерального казначейства в системе удалённого финансового документооборота и др.

С радостью продемонстрируем Вамвсе возможности решения

Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie, которые обеспечивают правильную работу сайта. Принять Подробнее…

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.

Обмен по универсальному виду сведений можно представить так:

На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:

• номер заявления портала и сведения, позволяющие определить услугу;
• целевое подразделение, к которому пользователь обращается за услугой.

Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.

Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.

Очереди сообщений и процесс взаимодействия

В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.

Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

На каждый запрос может поступить как успешный, так и неуспешный ответ.

Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:

• Произошло расхождение справочных данных на портале и у поставщика;
• Нужного соответствия просто нет в настройках системы поставщика.

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

Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.

На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.

Постановка задачи

С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.

Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.

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

Авторы продукта

Николай Емельянов

Руководитель напраления

Михаил Желудков

Руководитель разработки

<!–

–>

Александр Беседин

Главный разработчик

<!–

–>

Караева Людмила

Аналитик направления

<!–

–>

Чем занимаемся

Мы — это практика автоматизации процессов в сфере
недвижимости и финансов (BPM) в Лиге Цифровой Экономики.
Занимаемся разработкой решений для информационного взаимодействия между коммерческими
компаниями, банками и государственными структурами.
Практика работает по двум направлениям — автоматизация бизнес-процессов коммерческих
компаний и высоконагруженных решений для государственных систем.

• 2020
• 2019
• 2018

11 октября — Реализация цифровой системы Нотариата

6 сентября — Подключение ДОМ.РФ ко ФГИС ЕГРН Росреестра

20 июля — Реализация нового государственного СМЭВ-адаптера

12 мая — Успешное проведение рядя консалтинговых услуг для бизнеса по подключению к информационным системам Росреестра

13 марта — Создание продукта по работе с электронной подписью

9 декабря — Создание ЦК по работе с госсектором

17 ноября — Запуск информационного взаимодействия между АО ДОМ.РФ и Росреестром

23 октября — Создание продукта для бизнес-сообщества по взаимодействия с Росреестром – “Колоцинт-РР”

15 июня — Создание продукта по работе с ГИС ГМП

31 марта — Реализация цифровой платформы в ДОМ.РФ по учетно-регистрационным действиям объектов недвижимости

10 октября — Запуск первого в России блокчейн-проекта между Фондом защиты прав граждан, Росреестром и агентством ипотечного жилищного кредитования

1 июля — Создание ИТ-экосистемы для работы с электронными закладными в России

15 мая — Перевод первых территориальных отделений Росреестра на ФГИС ЕГРН

1 февраля — Запуск ИТ-системы Фонда защиты прав граждан

15 января — День образования практики BPM в Лиге Цифровой Экономики

Subscribe Newsletter

Enter your email address for
our
weekly new update

Что еще мы можем
предложить