Identity Provider - Рекомендации по развертыванию версии 3 - Инструкции - FEDURUS

Shibboleth IdPv3: Рекомендации по развертыванию в контексте федеративной среды FEDURUS

Данный раздел содержит рекомендации по развертыванию программного обеспечения Shibboleth Identity Provider версии 3 в среде федерации FEDURUS и рекомендации по обновлению существующего компонента Shibboleth Identity Provider версии 2.

1. Введение

Программное обеспечение третьего поколения Shibboleth Identity Provider software IdPv3 является результатом больше чем двух лет активной работы разработчиков. Программное обеспечение существенно модернизировано и содержит большое число новых функций наряду с модернизированной архитектурой, основанной на Spring Web Flow.

2. Предлагаемый подход при миграции с Shibboleth IdPv2.x

Примечание: Не рассматривайте вариант оперативного обновления с версии Shibboleth IdPv2 до IdPv3, это слишком рискованно!

Если Вы отвечаете за работоспособность технологического компонента IdPv2 в среде федерации FEDURUS, выполните следующие три шага:

Установите IdPv3 на абсолютно новой машине (физической или виртуальной) в соответствии с Инструкцией по установке Shibboleth Identity Provider 3.
Используйте инструкции по обновлению, включенные в инструкцию по установке для получения новых параметров конфигурации IdPv3 из существующих в IdPv2.
Только после полного тестирования произведите замену существующего экземпляра технологического компонента IdPv2 новым IdPv3.

Текущий entityID должен быть сохранен, как и все хранящиеся постоянные идентификаторы пользователей persistentIDs! Однако, в случае использования дополнительного расширения uApprove перенос данных, связанных с этим модулем, невозможен про причине значительной модернизации IdPv3. Пользователи должны будут снова согласится с "Условиями использования" и одобрить набор "выпускаемых" атрибутов.

3. Стратегия развертывания

Для развертывания технологического компонента Shibboleth IdPv3 в среде федерации FEDURUS, проект рекомендует использование следующего программного обеспечения.

3.1 Операционные системы: Linux long-term support

Растущее число ресурсов требует безопасности и надежности работы технологического компонента Identity Provider. Операционные системы промышленного масштаба с длительным сроком сопровождения (long-term support) предоставляют стабильную базу, не требующую ежегодного обновления операционной системы или среды функционирования Java Runtime Environment, сервера приложений или сервера HTTP. Инструкция содержит описание установки для Ubuntu Server 14.04 LTS и Red Hat Enterprise Linux 7 / CentOS 7.

3.2 Java & Servlet Container: OpenJDK 7, Apache Tomcat 7 & Apache HTTP Server 2.4

FEDURUS рекомендует и документирует в инструкции использование OpenJDK 7. Это стандартный пакет в выбранных дистрибутивах операционных систем, оперативно получающий обновления безопасности. Положительный опыт, полученный при использовании OpenJDK с IdPv2, проект считает достаточным, чтобы принять такое решение.
Проект Shibboleth рекомендует использовать Oracle "standard" JVM вместо OpenJDK, но Oracle JVM не входит в состав стандартных пакетов вышеупомянуты операционных систем. В связи с этим возможно не своевременное получение исправлений обнаруженных уязвимостей.

IdPv3 необходим Java 7 или более новой версии. FEDURUS рекомендует и документирует использование Java 7. Java 8 не является (на данный момент) версией по умолчанию для выбранных дистрибутивов операционных систем. Кроме того, в Java 8 введена новая подсистема (кодовое название 'Nashorn') выполнения сценариев (scripting engine), которая не имеет обратной совместимости с подсистемой (кодовое название 'Rhino'), используемой в Java 7 . IdP использует данную подсистему для преобразования значений некоторых атрибутов пользователя в файле attribute-resolver.xml. На данном этапе недостаточно практического опыта использования 'Nashorn'. Поэтому, более безопасно продолжать использование 'Rhino' и отложить обновление до 'Nashorn' до будущей модернизации.

Технологический компонент IdPv2 включал в себя веб сервер Apache в качестве внешней части к контейнеру сервлетов Tomcat. Из нашего опыта, данный вариант был стабильным и надежным решением для работы компонента Identity Provider. Поэтому, FEDURUS рекомендует и документирует использование Apache Tomcat 7 вместе с Apache HTTP Server 2.4 в процессе эксплуатации компонента Identity Provider.

3.3 База данных для persistentID и пользовательских соглашений: PostgreSQL

Существенное изменение для IdPv3 в рекомендации СУБД для хранения persistentID и параметров "пользовательских соглашений". Проект рекомендует и документирует использование PostgreSQL. Данная СУБД длительное время существует как общедоступное программное обеспечение с акцентом на соблюдение стандартов SQL.
В предыдущей версии технологического компонента IdP использовалась СУБД MySQL. С приобретением MySQL компанией Oracle, обновления безопасности для MySQL больше не предоставляются отдельно, а только как часть большого пакета 'Critical Patch Update'. Это препятствует частичному переносу обновлений безопасности, который важен для дистрибутивов с длительным сроком сопровождения.

FEDURUS предоставит инструкции по переносу данных persistentID из существующей СУБД MySQL.

В отличие от проекта Shibboleth, FEDURUS рекомендует продолжать хранение параметров "пользовательских соглашений" в СУБД. В этом случае параметры "пользовательского соглашения" хранятся независимо от веб браузера или устройства. Пользователь должен согласиться с условиями использования только один раз, что делает его взаимодействие с системой более комфортным.

3.4 Хранение пользовательских сессий: сессии клиента хранятся в куки (cookies)

У администратора IdP есть четыре варианта хранения параметров сессии пользователя. FEDURUS рекомендует вариант хранения сессий пользователя в защищенных куки (secured cookies) браузера. Этот вариант используется в конфигурации, рекомендуемой проектом Shibboleth. Данный способ легко поддерживает объединение в кластеры (см. ниже пункт 5) без необходимости хранения данных на стороне технологического компонента и синхронизации между узлами кластера. Однако, как недостаток, в данном варианте невозможна поддержка технологии "единого выхода" (см. ниже пункт 4).

3.5 Конфигурация атрибутов пользователя разделяется на несколько файлов

FEDURUS больше не предоставляет один общий файл конфигурации атрибутов пользователя attribute-resolver.xml, а разделяет его на несколько частей. Первая часть, файл attribute-resolver-fedurus-core.xml, содержит набор обязательных и дополнительных атрибутов для возможности работы в федеративной среде. Файл attribute-resolver-other.xml содержит весь остальной набор атрибутов используемых схем. Для работы в федеративной среде IdP должны поддерживать выпуск обязательного набора атрибутов пользователя. Если IdP необходим выпуск дополнительных атрибутов для локального использования или двустороннего взаимодействия с ресурсом не участвующим в федерации, настоятельно рекомендуем поместить их в отдельный attribute-resolver-local.xml файл.

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

3.6 Шаблоны страниц аутентификации и сообщений об ошибках:

Для отображения страниц аутентификации и сообщений об ошибках в IdPv3 проект Shibboleth перешел от использования .jsp к шаблонам .vm, интерпретируемых процессором (обработчиком шаблонов) Velocity, базирующемся на Java. FEDURUS предоставит файлы локализации для данных шаблонов.

4. Поддержка "единого выхода" (Single Logout Support)

Поддержка технологии "единого выхода" (SLO или single logout) в IdPv3.1.x имеет ограничения, которые были и в IdPv2.4.x. Сессия пользователя может быть завершена IdP, но не сессия на стороне ресурсов, за исключением SP инициирующего "единый выход". Полная реализация данной технологии планируется в последующих выпусках в III квартале 2015. Для внедрения SLO в текущей версии 3.1 требуется хранение сессий пользователей на стороне сервера.

Только после полной реализации данной технологии проектом Shibboleth, FEDURUS предоставит дополнительную информацию о настройке данного функционала технологического компонента IdP.

5. Кластеризация, балансировка нагрузки, высокая доступность

В документации проекта Shibboleth представлена информация по использованию кластеризации IdP. Настоятельно рекомендуется ознакомится с данными документами перед проектированием IdP.

Для IdP функционирующих в среде федерации FEDURUS, при объединении в кластер сохраняется требование наличия хранилища на стороне сервера, при этом постоянные идентификаторы необходимо хранить в реляционной базе данных. Хранение только идентификаторов persistentID и пользовательских соглашений характеризуется относительно не большим количеством операций записи и более частыми операциями чтения данных. Значительно большее число операций записи данных будет при хранении в базе данных пользовательских сессий (при отказе хранения этой информации в cookies браузера пользователя).

FEDURUS не дает рекомендаций и не документирует какой-либо определенный подход объединения в кластеры по причине отсутствия собственного опыта. Информация о вашем опыте в этой области будет интересна всем участникам проекта.