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

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

Система управления доступом (N3.СУД)

Общие сведения

Система управления доступом (N3.СУД) предназначена авторизации и аутентификации внешних клиентов платформы N3.Здравоохранение при обращении к компонентам платформы, а также запросе данных, хранящихся в ней. N3.СУД реализует модель доступа, основанную на утверждениях, а также поддерживает внешние провайдеры авторизации такие как LDAP и ЕСИАиА.

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

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

LDAP-авторизация

На стороне системы управления доступом N3.СУД реализована возможность предоставления доступа с использованием данных учетной записи LDAP (Lightweight Directory Access Protocol). Подробные сведения об использовании LDAP-авторизации приведены в соответствующем разделе.

Авторизация от лица медицинской организации

На стороне системы управления доступом N3.СУД реализована возможность определения прав на основе утверждений (claims base). Условно, утверждения можно сгруппировать в две группы: базовые и дополнительные.

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

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

Базовые правила доступа

Базовыми политиками N3.СУД является соблюдение при передаче данных следующих условий:

  1. МИС, от которой идёт обращение, является Участником информационного обмена N3.Здравоохранение
  2. МО, от которой идёт обращение, существует в справочнике МО (OID справочника 1.2.643.2.69.1.1.1.64)
  3. Медицинский работник, от имени которого идёт обращения, является сотрудником данной МО

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

Работа дополнительных политик доступа предполагает, что для получения ключа доступа от N3.СУД необходимо соблюдение условий не только всех базовых политик, но и как минимум одной из работающих дополнительных политик:

  1. Политика "Пациент обслуживается". Условием работы данной политики является наличие у пациента открытого случая обслуживания в той МО, от которой идёт обращение к СУД
  2. Политика "Пациент обслуживался". Условием работы данной политики является наличие у пациента случая обслуживания в той МО, от которой идёт обращение к СУД, закрытого менее 30 дней назад
  3. Политика "Пациент прикреплён". Условием работы данной политики является факт прикрепления пациента к МО, от которой идёт обращение к СУД, в рамках ТФОМС.

Общий порядок получения доступа

Общий порядок получения доступа к данным ИЭМК пациента через Портал врача отображается на диаграмме.

Процесс представляет собой последовательность следующих шагов:

  • Получение идентификатора карточки пациента в ИЭМК;
  • Формирование запроса к СУД;
  • Получение маркера доступа;
  • Вызов Портала ИЭМК.

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

 

Получение идентификатора карточки пациента в ИЭМК

Запрос идентификатора карточки пациента в ИЭМК производится путем вызова метода GetPatient модуля работы с пациентов сервиса ИЭМК.

Для вызова метода и получения идентификатора достаточно указать следующие параметры:

  • guid - ключ доступа к сервису ИЭМК;
  • idLPU - идентификатор МО;
  • IdPatientMIS - идентификатор карточки пациента в МИС МО;
  • idSource = Reg (константа).

 

Параметр ответа Patient.IdGlobal и будет искомым идентификатором.

Формирование тела запроса

Формирование и отправка запроса к СУД состоит из следующих шагов:

  1. Формирование запроса;
  2. Кодирование запроса с помощью Base64;
  3. Формирование запроса к СУД и кодирование URL.

Ниже указанные шаги описаны более подробно.

 

Формирование запроса

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

Текущая реализация СУД предполагает использование следующих параметров для построения запросов на доступ:

  • СНИЛС медицинского работника;
  • GUID медицинской организации;
  • OID МИС;
  • Идентификатор карточки пациента в ИЭМК
  • Фамилия медицинского работника;
  • Имя медицинского работника;
  • Отчество медицинского работника;
  • Логин учетной записи LDAP медицинского работника\ организации;
  • Пароль учетной записи LDAP медицинского работника\ организации.

 

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

${<ИмяАтрибута>}, где ИмяАтрибута - значение параметра

В текущем решении используются следующие атрибуты:

  • ${MP.snils} – СНИЛС медицинского работника.
  • ${MO.guid} - GUID медицинской организации (См. значения справочника urn:oid:1.2.643.2.69.1.1.1.64 подсистемы НСИ.).
  • ${MIS.oid} - OID МИС (См. значение справочника urn:oid:1.2.643.2.69.1.2 подсистемы НСИ.)
  • ${Patient.IdGlobal} - Идентификатор пациента ИЭМК.
  • ${MP.lastName} – Фамилия медицинского работника.
  • ${MP.firstName} – Имя медицинского работника.
  • ${MP.patronymic} – Отчество медицинского работника.
  • ${LDAP.login} – Логин учетной записи LDAP
  • ${LDAP.password} - Пароль учетной записи LDAP

 

Более подробно о сценариях и работе с шаблонами сказано в следующих разделах:

 

Кодирование запроса с помощью Base64

На этом шаге производится кодирование полученного XML-документа c корневым элементом XACMLAuthzDecisionQuery с помощью кодировки Base64 (см спецификацию «The Base64 Alphabet» приведена в Table 1 в RFC 4648 и в RFC 2045 для операций кодирования и декодирования)

Формирование запроса к СУД и URL-кодирование

URL-кодирование

Сформированное тело запроса подвергается URL-кодированию, согласно требованиям, изложенным в стандарте языка JavaScript ECMAScript 2015 (6th Edition, ECMA-262).

Запрос к СУД

Полученная на предыдущем шаге кодированная в URL и Base64 строка используется для формирования тела запроса в СУД. Тело запроса должно иметь следующий вид:

grant_type=urn:ietf:params:oauth:client-assertion-type:saml2-bearer
&assertion=<кодированный контент>
&scope=iemk_portal+openid

где,

<кодированный контент> - кодированная Base64-строка для XML-документа c корневым элементом XACMLAuthzDecisionQuery

Получение маркера доступа

Далее требуется отправить POST запрос в сервис СУД с использованием метода POST по адресу:

/connect/token

где - адрес сервиса СУД

В ответ на сообщение от СУД будет получено сообщение следующего вида:

{"access_token":"<маркер доступа>","expires_in":3600,"token_type":"Bearer"}

где <маркет доступа> - последовательность символов.

Например:

{
"access_token":
"d3c2bdbb1300a99d9e5a8b0f49843a555af39f7efe009775acabdfdfd2e9f5a2",
"expires_in": 3600,
"token_type": "Bearer"
}
Заголовок POST-запроса в СУД

Заголовок POST-запроса в сервис СУД должен содержать параметры, приведенные в таблице

Свойство Значение Примечание
Authorization Basic {учетные данные} Учетные данные представляют собой строку в формате {логин}:{пароль}. Далее строка кодируется Base64. Например, учетные данные mis1:secret будут представлены в виде строки: bWlzMTpzZWNyZXQ=
Accept application/json Константа
Content-Type application/x-www-form-urlencoded Константа
Host <N3.ACS.host> <N3.ACS.host> - DNS имя или IP адрес узла сети, на котором размещен СУД. Например, login-test.zdrav.netrika.ru
Expect 100-continue Константа
Connection Keep-Alive Константа
Content-Length <ДлинаДанных> Размер передаваемых данных в байтах. В качестве передаваемых данных рассматривается тело HTTP запроса, сформированное на шаге Формирование запроса к СУД и кодирование URL.
Пример:
POST https://login.zdrav.netrika.ru/connect/token HTTP/1.1
Authorization: Basic bWlzMTpzZWNyZXQ=
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: login.zdrav.netrika.ru
Content-Length: 5188
Expect: 100-continue
Connection: Keep-Alive

Формирование URL и вызов Портала

Для Вызова портала ИЭМК полученный маркер доступа от СУД должен быть использован для формирования URL следующего вида:

<IEMK.Portal.URL>/Patient/<Patient.IdGlobal>/Encounters?access_token=<маркет доступа>

где:

  • - URL Портала ИЭМК (т.е. базовый адрес портала);
  • - Идентификатор пациента ИЭМК.
  • <Маркер доступа> - маркер доступа, полученный из сервиса СУД в ответ на запрос, сформированный на шаге, описанном в пункте 3.6.

 

Пример:

http://r78-rc.zdrav.netrika.ru/IEMKUI/Patient/15500e82-75ad-4e31-9e58-4d9d0957d20a/Encounters?access_token=82ec05795d7d72d28f2dfe300d2fbfcdbf4faea3f9171aac10f26b5b991be870

Веб-интерфейс Портала ИЭМК может быть открыт с помощью агента (браузера) при использовании HTTP метода GET. То есть, например, указанный URL может быть введен в адресную строку браузера.

В случае, если сформированный в СУД и используемый в запросе к Порталу маркер доступа, корректен и разрешает доступ к данным ИЭМК Пациента, то Веб-интерфейса Портала ИЭМК позволит просматривать все записи и документы, связанные с данным Пациентом. Если маркер доступа некорректен относительно запрашиваемых через портал данных ИЭМК Пациента, то в Веб-интерфейсе Портала ИЭМК будет выведено сообщение об отказе в доступе. Если маркер доступа устарел, то пользователь будет перенаправлен на страницу авторизации с помощью учётной записи LDAP.

LDAP-авторизация

Ниже приведена информация, касающаяся взаимодействия с СУД для авторизации медицинского работника в Портале врача с помощью учетной записи LDAP.

Необходимые параметры запроса

Для формирования XACML-запроса при использовании LDAP-авторизации, требуется подготовить следующие данные для дальнейшего формирования запроса к сервису СУД:

  • Логин учетной записи LDAP;
  • Пароль учетной записи LDAP;
  • GUID МО по справочнику МО региона (См. значения справочника urn:oid:1.2.643.2.69.1.1.1.64 подсистемы НСИ);
  • OID МИС по справочнику Участников информационного обмена НСИ ЕГИСЗ региона (См. значение справочника urn:oid:1.2.643.2.69.1.2 подсистемы НСИ);

 

Шаблон запроса

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

${<ИмяАтрибута>}, где ИмяАтрибута - последовательность символов, являющихся именем атрибута.

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

<n3:System oid="urn:oid:1.2.643.2.69.1.1.1.64">
	<n3: guid="${MO.guid}" />
</n3:System>

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

Мнемоника Значение
${MO.guid} GUID медицинской организации
${MIS.oid} OID МИС
${LDAP.login} Логин учетной записи LDAP
${LDAP.password} Пароль учетной записи LDAP

Авторизация от лица МО

Запрос на доступ со стороны МО

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

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

Для формирования XACML-запроса при использовании запроса со стороны МО, требуется подготовить следующие данные для дальнейшего формирования запроса к сервису СУД:

  • Идентификатор карточки пациента, ранее переданной в сервис ИЭМК;
  • СНИЛС медицинского работника;
  • ФИО медицинского работника;
  • GUID МО по справочнику МО региона (См. значения справочника urn:oid:1.2.643.2.69.1.1.1.64 подсистемы НСИ);
  • OID МИС по справочнику Участников информационного обмена НСИ ЕГИСЗ региона (См. значение справочника urn:oid:1.2.643.2.69.1.2 подсистемы НСИ);

 

Также в запросе при необходимости могут быть указаны следующие данные:

  • СНИЛС пациента
  • ОМС пациента

 

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

 

Шаблон запроса

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

${<ИмяАтрибута>}, где ИмяАтрибута - последовательность символов, являющихся именем атрибута.

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

<n3:System oid="urn:oid:1.2.643.2.69.1.1.1.64">
	<n3: guid="${.guid}" />
</n3:System>

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

Мнемоника Значение
${MP.snils} Номер СНИЛС медицинского работника
${MP.lastName} Фамилия медицинского работника
${MP.firstName} Имя медицинского работника
${MP.patronymic} Отчество медицинского работника
${MO.guid} GUID медицинской организации
${MIS.oid} OID МИС
${Patient.IdGlobal} Идентификатор карточки пациента
${Patient.snils} Номер СНИЛС пациента
${Patient.oms} Номер ОМС пациента