Приложение А. Использование ЕСИА в целях идентификации и аутентификации посредством стандарта SAML 2.0

Приложение А. Использование ЕСИА в целях идентификации и аутентификации посредством стандарта SAML 2.0

А.1 Общие сведения о стандарте SAML 2.0

Взаимодействие ИС с ЕСИА с целью идентификации и аутентификации осуществляется посредством электронных сообщений, основанных на стандарте SAML 2.0.

SAML 2.0 - основанный на XML стандарт по обмену информацией (утверждениями) об аутентификации и авторизации между доверенными доменами безопасности.

Основными компонентами SAML 2.0 являются:

1. Утверждение - информация о подлинности, атрибутах и назначениях;

2. Протокол - правила формирования запросов и ответов в процессе взаимодействий через SAML 2.0.

3. Связывание - отображение протокол SAML 2.0 на транспортные протоколы связи и передачи сообщений;

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

Рисунок 6 - Основные компоненты SAML 2.0

SAML 2.0 определяет синтаксис и семантику утверждений, относящихся к аутентификации, атрибутам и авторизационной информации. Определены следующие типы утверждений:

- утверждение по аутентификации - определяет, что данный субъект прошел аутентификацию определенным способом в определенный момент времени;

- утверждение по авторизации - определяет, на какие действия авторизован конкретный субъект;

- утверждение по атрибутам - определяет специфическую информацию о конкретном субъекте.

SAML 2.0 определяет способ передачи утверждений в протоколах. В ЕСИА используются следующие протоколы SAML 2.0 типа запрос/ответ:

- Authentication Request Protocol (протокол запроса аутентификации) - определяет способы, которыми аутентифицированный субъект может запросить утверждения, содержащие аутентификационные данные и атрибуты субъекта;

- Single Logout Protocol (протокол единого выхода) - определяет механизм одновременного завершения активных сессий, ассоциированных с аутентифицированным субъектом. Выход может инициироваться пользователем или поставщиком идентификации.

Связывания SAML 2.0 определяют, как различные сообщения протоколов SAML 2.0 могут передаваться поверх транспортных протоколов (например, SOAP, HTTP). B ЕСИА используются следующие связывания SAML 2.0:

- HTTP Redirect - определяет, как сообщения протокола SAML 2.0 могут передаваться, используя сообщения НТТР Redirect (ответы с кодом состояния 302);

- HTTP POST - определяет, как сообщения протокола SAML 2.0 могут передаваться с использованием сообщений НТТР POST.

Профили SAML 2.0 определяют, какие утверждения, протоколы и связывания SAML 2.0 могут использоваться в конкретных вариантах использования. В ЕСИА используются следующие профили SAML 2.0:

- Web Browser SSO - определяет, как реализовать однократную аутентификацию в стандартных веб-браузерах;

- Single Logout - определяет, как выполнить одновременный выход из всех сессий.

Как правило, поставщику услуг требуется детальная информация о результатах проведенной аутентификации. Эта информация содержится в контексте аутентификации, передаваемом в утверждениях SAML 2.0. Аутентификационный контекст (authentication context) определяет синтаксис для описания механизмов аутентификации.

А.2 Общие рекомендации по реализации интерфейсов поставщика услуг

Для реализации интерфейсов поставщика услуг можно использовать уже разработанные различные реализации поставщиков услуг с открытым кодом. Одним из таких поставщиков услуг является OIOSAML, реализованный под различные платформы. Различные реализации OIOSAML можно посмотреть на информационном ресурсе http://digitaliser.dk/group/42063/resources.

Примечание. В сборки последних версий OIOSAML разработчики стали включать библиотеки OpenSAML, которые несовместимы с ЕСИА. В настоящий момент с ЕСИА совместима версия 2.4.1. OpenSAML. Скачать данную версию можно по ссылке: http://www.shibboleth.net/downloads/java-opensaml/2.4.1.

Еще одним возможным вариантом реализации поставщика услуг для сред PHP является SimpleSAMLphp. Более подробную информацию о SimpleSAMLphp можно получить на информационном ресурсе http://simplesamlphp.org.

При самостоятельной реализации интерфейсов поставщика услуг на Java или C++ одним из возможных вариантов является использование набора библиотек с открытым кодом OpenSAML (строго версии 2.4.1.), который поддерживает работу со спецификациями SAML версии 1.0, 1.1 и 2.0. Подробную информацию о библиотеках OpenSAML можно посмотреть на информационном ресурсе https://wiki.shibboleth.net/confluence/display/OpenSAML/Home. Примеры кода по использованию OpenSAML для Java приведены в разделе А.7.

А.3 Общие требования к реализации интерфейса поставщика услуг

Интерфейсы поставщика услуг должны соответствовать следующим профилям SAML 2.0:

- Web Browser SSO с учетом рекомендаций Interoperable SAML 2.0 Web Browser SSO Deployment Profile;

- Single Logout.

Запрос к системе ЕСИА от информационной системы на идентификацию и аутентификацию пользователя должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:

- алгоритм c14n для каноникализации сообщения в формате XML;

- алгоритмы SHA-1 / SHA-256 / SHA-512 и RSA - для вычисления цифрового отпечатка сообщения и кода подтверждения целостности сообщения. В качестве протокола доставки должен использоваться метод связывания HTTP-redirect;

Ответ с результатами идентификации и аутентификации пользователя, сформированный системой ЕСИА, подписывается с помощью закрытого ключа системы ЕСИА и преобразуется с использованием открытого ключа информационной системы. При этом используются следующие алгоритмы:

- алгоритм c14n для каноникализации сообщения в формате XML;

- алгоритмы SHA-1 / SHA-256 / SHA-512 и RSA - для вычисления цифрового отпечатка сообщения и кода подтверждения целостности сообщения;

- алгоритмы RSA и SHA-1 / SHA-256 / SHA-512 для передачи ключа преобразования сообщения на основе открытого ключа информационной системы, алгоритм AES для осуществления преобразования на переданном ключе. В качестве протокола доставки сообщения от системы ЕСИА информационной системе используется метод связывания HTTP POST.

Запрос к системе ЕСИА от ИС на завершение активной сессии пользователя должен осуществляться из браузера пользователя и должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:

- c14n;

- SHA-1 / SHA-256 / SHA-512;

- RSA.

В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

Запрос от системы ЕСИА к ИС на завершение активной сессии пользователя подписывается с использованием закрытого ключа системы ЕСИА. При этом используются следующие алгоритмы:

- c14n;

- SHA-1 / SHA-256 / SHA-512;

- RSA.

В качестве протокола доставки используется метод связывания HTTP-redirect.

Ответ с результатами завершения активной сессии пользователя от информационной системы к системе ЕСИА должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:

- c14n;

- SHA-1 / SHA-256 / SHA-512;

- RSA.

В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

Ответ с результатами завершения активной сессии пользователя от системы ЕСИА к информационной системе передается подписанным с помощью закрытого ключа системы ЕСИА с использованием следующих алгоритмов:

- c14n;

- SHA-1 / SHA-256 / SHA-512;

- RSA.

В качестве протокола доставки используется метод связывания HTTP-redirect.

А.4 Описание форматов электронных сообщений SAML 2.0 в ЕСИА

В данном разделе описываются следующие протоколы SAML 2.0, используемые ЕСИА при формировании электронных сообщений:

- протокол запроса аутентификации;

- протокол единого выхода.

Запрос аутентификации (AuthnRequest)

Запрос аутентификации (AuthnRequest) представляет собой XML-документ, который содержит следующие элементы:

1. saml2p:AuthnRequest - описывает параметры запроса AuthnRequest и содержит следующие атрибуты:

- AssertionConsumerServiceURL - URL провайдера услуг, предназначенный для обработки ответов от поставщика идентификации (необязательный);

- Destination - URL-адрес ИС-поставщика идентификации, предназначенный для обработки AuthnRequest;

- ID - уникальный идентификатор сообщения;

- IssueInstant - дата создания запроса;

- ProtocolBinding - используемая SAML привязка.

2. saml2:Issuer - идентификатор поставщика услуг, отправившего AuthnRequest (является вложенным по отношению к элементу saml2p:AuthnRequest).

Структура AuthnRequest:

Рисунок 7 - Структура AuthnRequest

Пример AuthnRequest:

Для сгенерированного SAML 2.0 сообщения с запросом AuthnRequest должно быть выполнено связывание (binding) с протоколом HTTP по методу HTTP-Redirect с учетом следующих особенностей:

- сообщение подписывается с помощью электронной подписи поставщика услуг, причем подписана должна быть строка запроса на аутентификацию пользователя;

- подписанное сообщение сжимается и кодируется в кодировке Base64.

В процессе связывания формируется конечный URL AuthnRequest, который в качестве GET-параметров должен содержать:

- SAMLRequest - AuthRequest в конечном виде;

- SigAlg - алгоритм подписи запроса, с помощью которого выполнялась подпись запроса аутентификации;

- Signature - подпись, полученная в результате подписания запроса аутентификации.

Пример URL AuthnRequest:

Ответ на запрос аутентификации (AuthnResponse)

В случае успешной аутентификации поставщик идентификации формирует ответ на запрос аутентификации - AuthnResponse, который содержит утверждение (Assertion) об аутентификации. AuthnResponse представляет собой XML-документ со следующей структурой:

Рисунок 8 - Структура AuthnResponse

Элементы saml2:Issuer и saml2:Signature содержат идентификатор поставщика идентификации и электронную подпись, созданную с помощью сертификата поставщика идентификации.

Элемент saml2:Subject содержит информацию о AuthnRequest, которому соответствует данный AuthnResponse, и представляет собой следующую структуру:

Рисунок 9 - Структура saml2:Subject

Элемент saml2:NameID содержит уникальный идентификатор, присвоенный поставщиком идентификации соответствующему AuthnRequest.

Элемент saml2:SubjectConfirmationData содержит набор атрибутов, в том числе:

- InResponseTo - содержит идентификатор AuthnRequest (соответствует значению атрибута ID);

- NotOnOrAfter - содержит дату, до которой данный AuthnRequest действителен.

- Recipient - URL обработчика AuthnResponse (соответствует значению AssertionConsumerServiceURL).

Элемент saml2:Condition содержит описание условий, при которых данный AuthnResponse считается действительным. Данный элемент имеет два атрибута - NotBefore и NotOnOrAfter, которые указывают на временной промежуток, в который данный AuthnResponse действителен. Также saml2:Condition имеет вложенный элемент saml2:AudienceRestriction, который содержит элемент saml2:Audience с указанием уникального идентификатора поставщика услуг (entity_id). Уникальный идентификатор системы в ЕСИА (entity_id) не должен содержать символов кириллицы.

Элементы saml2:AuthnStatement и saml2:AttributeStatement содержат информацию о результатах аутентификации.

Элемент saml2:AuthnStatement имеет два атрибута:

- AuthnInstant - дата аутентификации;

- SessionIndex - уникальный идентификатор сессии пользователя (с помощью него, например, выполняется повторная аутентификация и операция Logout).

Элемент saml2:AttributeStatement содержит атрибуты пользователя и имеет следующую структуру:

Рисунок 10 - Структура saml2:AttributeStatement

Элемент saml2:Attribute имеет три атрибута:

- FriendlyName - сокращенное наименование атрибута;

- Name - полное наименование атрибута;

- NameFormat - формат полного наименования атрибута.

Элемент saml2:AttributeValues состоит из двух атрибутов: xmlns:xsi и xsi:type. Эти атрибуты определяют формат значения атрибута пользователя.

Пример AuthnResponse приведен в разделе А.9.

Запрос завершения активной сессии пользователя (LogoutRequest)

Запрос завершения активной сессии (LogoutRequest) представляет собой XML-документ со следующей структурой:

Рисунок 11 - Структура LogoutRequest

Завершение активной сессии пользователя может быть инициировано как со стороны поставщика услуг, так и со стороны поставщика идентификации. В случае, если завершение сессии инициирует поставщик услуг, то LogoutRequest должен содержать обязательный элемент saml2:SessionIndex.

Элемент saml2:LogoutRequest имеет следующие атрибуты:

- Destination - содержит URL обработчика LogoutRequest. В случае если завершение сессии инициировано поставщиком услуг, то содержит URL поставщика идентификации, и наоборот, если инициирован поставщиком идентификации - то URL SP.

- ID - содержит уникальный идентификатор сообщения.

- IssueInstant - дата формирования сообщения.

- Reason - присутствует в случае инициализации завершения сессии со стороны поставщика услуг.

Элемент saml2:Issuer в качестве значения содержит идентификатор (entity_id) инициатора завершения сессии - либо поставщика услуг, либо поставщика идентификации.

Элемент saml2:NameID в качестве значения содержит уникальный идентификатор присвоенный поставщиком идентификации соответствующему AuthnRequest.

Элемент saml2:SessionIndex содержит уникальный идентификатор пользователя, созданный при аутентификации.

Запрос на завершение сессии должен производиться из браузера (от имени пользователя). В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

Примеры запроса завершения сессии:

Ответ на запрос завершения активной сессии (LogoutResponse)

Ответ на запрос завершения активной сессии (LogoutResponse) представляет собой XML- документ со следующей структурой:

Рисунок 12 - Структура LogoutResponse

Элемент saml2:LogoutResponse имеет следующие атрибуты:

- Destination - содержит URL обработчика LogoutResponse. В случае если завершение сессии инициировано поставщиком услуг, то содержит URL поставщика идентификации, и наоборот, если инициирован поставщиком идентификации - то URL поставщика услуг.

- ID - содержит уникальный идентификатор сообщения.

- InResponseTo - содержит идентификатор LogoutRequest.

- IssueInstant - дата формирования сообщения.

Элемент saml2:Issuer, в зависимости от инициатора завершения сессии, в качестве значения содержит идентификатор (entity_id) инициатора завершения сессии - либо поставщика услуг, либо поставщика идентификации.

Элемент saml2p:Status имеет вложенный элемент saml2p:StatusCode, имеющий атрибут Value, в качестве значения которого передается статус операции.

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

Примеры ответа на запрос завершения сессии:

А.5 Описание метаданных поставщика услуг

Метаданные поставщика услуг определяют способ описания конфигурационных данных (например, URL конечных точек веб-служб, ключи для проверки ЭП). Для описания метаданных ИС поставщика услуг используется язык XML. Структура файла метаданных ИС поставщика услуг приведена на рисунке 13.

МЕТАДАННЫЕ ПОСТАВЩИКА УСЛУГ

Рисунок 13 - Структура файла метаданных ИС поставщика услуг (пример)

Перечень атрибутов пользователя (организации), содержащихся в файле метаданных поставщика услуг, приведен в таблице 5. Системам, интегрированным с ЕСИА, рекомендуется не использовать или отказаться от использования устаревших утверждений SAML (см. Приложение Д.2).

Если у пользователя или организации отсутствуют те или иные атрибуты, то они не передаются в SAML-утверждениях.

Таблица 5 - Перечень атрибутов, содержащихся в файле метаданных поставщика услуг

N	Атрибут	Описание	Примечание
1.	assuranceLevel	Уровень достоверности идентификации пользователя. Возможны следующие значения: AL10 - упрощенная (непроверенная) учетная запись; AL15 - стандартная (проверенная) учетная запись; AL20 - подтвержденная учетная запись; AL30 - подтвержденная учетная запись (аутентификация по КЭП).	Рекомендуется использовать атрибуты: - personTrusted - для определения подтвержденных учетных записей; - authnMethod - для определения метода аутентификации.
2.	attachedToOrg	Признак включенности (присоединения) к организации	Необходимо использовать globalRole
3.	authnMethod	Метод аутентификации. Принимает следующие возможные значения: PWD - аутентификации по логину и паролю; DS - аутентификации по ЭП.
4.	authToken	Идентификатор сессии пользователя в системе ЕСИА
5.	birthDate	Дата рождения пользователя. Передается в формате DD-MM-YYYY
6.	firstName	Имя пользователя. Не более 256 символов
7.	gender	Пол пользователя. Принимает значения: MALE - мужской; FEMALE - женский.
8.	globalRole	Роль пользователя. Принимает следующие возможные значения: P - физическое лицо (Physical person); E - должностное лицо организации (Employee).
9.	inn	ИНН пользователя	Сохранен для обеспечения совместимости. Вместо него необходимо использовать personINN
10.	lastName	Фамилия пользователя. Не более 256 символов
11.	middleName	Отчество пользователя. Не более 256 символов
12.	memberOfGroups	Принадлежность пользователя к группам доступа ИС, осуществляющей идентификацию и аутентификацию должностных лиц ЮЛ. Передается в виде мнемоник системных групп через запятую	Использовать для определения принадлежности должностных лиц ЮЛ к группам доступа ИС
13.	name	Имя пользователя	Сохранен для обеспечения совместимости. Необходимо использовать lastName / firstName / middleName
14.	nsiId	Мнемоника ОГВ	Сохранен для обеспечения совместимости. Необходимо использовать orgOGRN и orgType
15.	orgAddresses	Адрес организации. Передается в виде XML документа	Каждый адрес в настоящее время описывается следующими атрибутами: <addressType> - тип адреса, в настоящее время может принимать значения: - ORG_LEGAL - юридический адрес; - ORG_POSTAL - почтовый адрес. <contryChar3Code> - код страны из трех символов (для России - RUS); <index> - индекс; <region> - субъект РФ; <district> - внутригородской район; <settlement> - населенный пункт; <street> - улица; <house> - дом; <corpus> - корпус; <structure> - строение; <flat> - квартира. Все атрибуты, начиная с индекса, - не более 256 символов.
16.	orgBranchKPP	КПП филиала, передается в формате XXXXXXXX, где X - цифры
17.	orgBranchName	Имя филиала
18.	orgContacts	Телефон и Email организации. Передается в виде XML документа	Каждый контакт в настоящее время описывается следующими атрибутами: <contactType> - тип контакта, в настоящее время может принимать значения: - PHN (телефон); - EML (адрес электронной почты); - FAX (факс). <value> - значение контакта, для телефона и факса имеет формат +7(XXX)XXXXXXX*YYYYYY, где *YYYYYY - добавочный номер (только для PHN, опционально, не более 6 цифр), для адреса электронной почты - не более 2000 символов; <verificationStatus> - - статус подтверждения контакта, где S - подтверждено, N - не подтверждено
19.	orgld	Идентификатор организации.	Сохранен для обеспечения совместимости. Для вновь подключаемых ИС необходимо использовать orgOid
20.	orgOid	Идентификатор организации. Любое положительное число
21.	orgKPP	КПП организации, передается в формате ХХХХХХХХ, где X - цифры
22.	orgLegalForm	Организационно-правовая форма организации. Передается название формы по справочнику ОКОПФ
23.	orgINN	ИНН организации пользователя. Передается в формате ХХХХХХХХХХ, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут globalRole = Е
24.	orgName	Наименование организации пользователя. Не более 4000 символов. Данный атрибут устанавливается только для случая, когда атрибут globalRole = Е
25.	orgShortName	Краткое наименование организации. Не более 500 символов
26.	orgOGRN	ОГРН организации пользователя. Передается в формате ХХХХХХХХХХХХХ, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут globalRole = Е
27.	orgPosition	Должность пользователя в организации. Не более 256 символов
28.	orgType	Тип организации. Принимает следующие возможные значения: В - индивидуальный предприниматель (Businessman); L - юридическое лицо (Legal entity); А - орган исполнительной власти (Agency). Данный атрибут устанавливается только для случая, когда атрибут globalRole = Е
29.	personCitizenship	Гражданство пользователя Гражданство передается по справочнику ОКСМ. Значение для России - "RUS"
30.	personEMail	Адрес электронной почты пользователя. Не более 2000 символов
31.	personINN	ИНН пользователя. Передается в формате ХХХХХХХХХХХХ, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут personType = R
32.	personMobilePhone	Номер мобильного телефона пользователя. Передается в формате +7(ХХХ)ХХХХХХХ, где X - цифры
33.	personOGRN	ОГРНИП пользователя. Передается в формате ХХХХХХХХХХХХХХХ, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут orgType = В
34.	personSNILS	СНИЛС пользователя. Передается в формате XXX-XXX-XXX XX, где X - цифры. Данный атрибут устанавливается только для стандартных (проверенных) и подтвержденных учетных записей
35.	personTrusted	Подтвержденная или неподтвержденная (упрощенная или стандартная) учетная запись пользователя Y - подтвержденная учетная запись; N - неподтвержденная (упрощенная или стандартная) учетная запись
36.	personType	Категория пользователя.	Сохранен для обеспечения совместимости. Необходимо использовать personCitizenship
37.	principalContacts	Контактные данные пользователя. Передается в виде XML документа	Каждый контакт в настоящее время описывается следующими атрибутами: <contactType> - тип контакта, в настоящее время может принимать значения: - EML (адрес электронной почты); - МВТ (мобильный телефон); - PHN (домашний телефон); - СЕМ (служебный адрес электронной почты пользователя, только для случая, когда атрибут globalRole = Е); - СРН (служебный номер телефона пользователя, только для случая, когда атрибут globalRole = Е). <value> - значение контакта, для телефонов имеет формат +7(ХХХ)ХХХХХХХ, для адреса электронной почты - не более 2000 символов; <verificationStatus> - статус подтверждения контакта, где S - подтверждено, N - не подтверждено
38.	principalDocuments	Документы пользователя. Передается в виде XML документа	Каждый документ в настоящее время описывается следующими атрибутами: <documentType> - тип документа, в настоящее время это 01 - паспорт гражданина РФ, 02 - документ иностранного гражданина, 05 - водительское удостоверение, 06 - полис ОМС, 07 - загранпаспорт, 08 - свидетельство о рождении, 09 - вид на жительство, 10 - разрешение на временное проживание, 11 - военный билет. <series> - серия документа, 4 символа для паспорта гражданина РФ; <number> - номер документа, 6 символов для паспорта гражданина РФ; <issueDate> - дата выдачи документа в формате YYYY-MM-DDT00:00:00; <verificationStatus> - статус подтверждения документа, где S - подтверждено, N - не подтверждено; <issuedBy> - орган, выдавший документ, строка не более чем из 2000 символов
39.	principalAddresses	Адрес пользователя. Передается в виде XML документа	Каждый адрес в настоящее время описывается следующими атрибутами: <addressType> - тип адреса, в настоящее время это "PERSON_REGISTRATION" - адрес регистрации, "PERSON_LIVE" - адрес проживания. <contryChar3Code> - трехбуквенный код страны. <index> - индекс. <house> - номер дома. <corpus> - корпус. <flat> - корпус.
40.	snils	СНИЛС пользователя. Данный атрибут устанавливается только для случая, когда атрибут personType = R	Сохранен для обеспечения совместимости. Необходимо использовать personSNILS
41.	systemAuthority	Полномочия должностного лица ОГВ. Передается в виде XML с указанием мнемоники полномочия и мнемоники системы	Использовать для определения полномочий должностных лиц ОГВ и ЮЛ. Для определения принадлежности представителей юридических лиц к группам доступа использовать memberOfGroups 28
42.	userld	Числовой идентификатор учетной записи пользователя в системе ЕСИА. Любое положительное число
43.	userName	Логин пользователя.	Сохранен для обеспечения совместимости. Необходимо использовать userld, personSNILS
44.	userType	Тип пользователя	Сохранен для обеспечения совместимости. Необходимо использовать globalRole

А.6 Шаблон файла метаданных

А.7 Рекомендации по указанию URL-адресов и выбору идентификатора поставщика услуг

Все URL-адреса в метаданных для продуктивной среды не должны содержать IP адреса - обязательно указание доменного имени портала информационной системы.

Примеры:

1. Правильно для Единого портала государственных услуг (функций):

2. Неправильно для Единого портала государственных услуг (функций):

При выборе идентификатора поставщика услуг (entityID) в продуктивной среде рекомендуется руководствоваться следующими принципами:

1. Поле EntityID должно однозначно соответствовать URL портала информационной системы которая интегрируется с ИС ЕСИА. Примеры:

- Единый портал государственных услуг (функций): entityID="http://www.gosuslugi.ru";

- Российская общественная инициатива: entityID="https://www.roi.ru".

2. Указанный в поле entityID URL не должен содержать IP адрес - обязательно указание доменного имени портала информационной системы. Примеры:

- Единый портал государственных услуг (функций): entityID="http://www.gosuslugi.ru";

- Некорректный пример: entityID="http://109.207.1.97".

3. Указанный в поле entityID URL не должен содержать символов кириллицы.

А.8 Примеры кода на языке Java по использованию OpenSAML

Пример кода поставщика услуг

Пример кода создания запроса <AuthnRequest>

Сообщение <AuthnRequest> может содержать и другие элементы, такие как <NameIDPolicy>, <RequestedAuthnContext>. Эти элементы создаются и добавляются в <AuthnRequest> аналогичным образом.

Сгенерированный запрос <AuthnRequest> должен быть преобразовано (marshaled) с использованием "org.opensaml.xml.io.Marshaller" и должен быть закодирован в кодировке Base64 в URL с использованием org.opensaml.xml.util.Base64.

Считывание ответа <Response>

Для считывания ответа <Response>, например, из сервлета, ответ извлекается из структуры "HttpServletRequest":

Извлеченное сообщение "responseMessage" необходимо преобразовать (unmarshal) и извлечь сообщение <Response>:

Далее с извлеченным SAML 2.0 Response message можно выполнять операции. Например, извлечем Subject's Name Id и сертификат:

А.9 Пример AuthnResponse