В университете одному и тому же человеку может понадобиться доступ к главному сайту, порталу для преподавателей, библиотечной системе, обучающей платформе и десятку других приложений — и никто не хочет входить в систему отдельно в каждое из них. Единый вход (SSO) решает эту проблему, позволяя пользователю пройти аутентификацию один раз, используя единый набор институциональных учётных данных, и получить доступ ко всем подключённым системам. Для сайта на Drupal, который находится в центре цифрового присутствия университета, интеграция с системой SSO учебного заведения — один из важнейших элементов построения платформы.
В этом руководстве объясняется, как работает интеграция SSO в Drupal и, что ещё важнее, как выбрать правильный подход. Мы рассмотрим четыре технологии, на которые опираются университеты — SAML, Shibboleth, LDAP и CAS, — когда каждая из них подходит, как работает интеграция на стороне Drupal, а также решения по управлению идентификацией и безопасности, которые остаются за рамками большинства пошаговых руководств.
Что на самом деле означает единый вход
Единый вход — это модель аутентификации, при которой пользователь входит в систему один раз через доверенный центральный орган, после чего автоматически распознаётся каждым подключённым к нему приложением. Ключевой принцип — и преимущество с точки зрения безопасности — состоит в том, что отдельные приложения никогда не работают напрямую с паролем пользователя. При наличии SSO учётные данные проверяются в одном месте, по единому набору правил, а не хранятся и проверяются отдельно каждой системой.
Для университета это важно сразу на нескольких уровнях. Студенты и сотрудники получают единую идентификационную запись для десятков сервисов. ИТ-отдел управляет аутентификацией централизованно, применяя единые правила для паролей и многофакторную аутентификацию повсеместно. А когда кто-то покидает учебное заведение, отключение одной центральной учётной записи разом лишает доступа ко всему, вместо того чтобы оставлять «осиротевшие» логины разбросанными по разным системам. Именно сочетание удобства и контроля делает SSO фактически обязательным требованием для любой серьёзной институциональной веб-платформы.
Основа основ: поставщик удостоверений и поставщик услуг
Любая настройка SSO включает в себя две роли, и понимание их делает всё остальное гораздо более понятным.
Поставщик удостоверений (IdP) — это доверенный центральный орган, который хранит идентификационные данные пользователей и проверяет учётные данные — например, служба Shibboleth учебного заведения, его Active Directory или сервер CAS. Поставщик услуг (SP) — это приложение, к которому пользователь хочет получить доступ — в данном случае сайт на Drupal. Когда пользователь пытается получить доступ к SP Drupal, тот передаёт процесс аутентификации IdP; IdP проверяет пользователя и отправляет обратно подтверждение вместе с такими атрибутами, как имя, электронная почта и роль; после этого Drupal предоставляет доступ на основании этого доверенного ответа. В стандартной университетской конфигурации Drupal выступает в роли поставщика услуг, а существующая система учебного заведения — в роли поставщика удостоверений. Правильно выстроить эти отношения — основа любой интеграции SSO.
Четыре подхода: SAML, Shibboleth, LDAP и CAS
Университеты обычно опираются на одну из четырёх технологий для SSO. Они пересекаются по своему назначению, но различаются происхождением, механизмом действия и областью наилучшего применения.
SAML
SAML (Security Assertion Markup Language) — это открытый стандарт, лежащий в основе большинства современных корпоративных решений SSO. Это XML-протокол для обмена данными аутентификации и авторизации между IdP и SP, интегрирующийся практически с любой крупной платформой управления идентификацией — Microsoft Entra ID, Okta, ADFS, Google Workspace и другими. В Drupal SAML обрабатывается с помощью сторонних (contributed) модулей, которые позволяют сайту выступать в роли поставщика услуг, делегируя аутентификацию любому IdP, совместимому с SAML. Это наиболее широко совместимый вариант и общая площадка, на которой могут «разговаривать» большинство других систем.
Shibboleth
Shibboleth — это конкретная, широко распространённая реализация SAML, глубоко укоренившаяся в академическом мире. Это основа федеративного доступа в сфере высшего образования и научных исследований — технология, лежащая в основе национальных и международных академических федераций, которые позволяют студенту войти в систему одного учебного заведения и получить доступ к ресурсам другого. Технически интеграция Drupal с Shibboleth является интеграцией SAML: Drupal выступает в роли поставщика услуг SAML, а Shibboleth служит поставщиком удостоверений. Если ваше учебное заведение входит в состав академической федерации идентификации, весьма вероятно, что именно к Shibboleth вы и будете подключаться.
LDAP
LDAP (Lightweight Directory Access Protocol) — это не протокол SSO в том же смысле, что и SAML: это протокол для обращения к каталогу пользователей, чаще всего — Microsoft Active Directory. Его роль в университете заключается в том, чтобы быть базовым источником идентификационных данных: он хранит информацию о том, кто существует, о членстве в группах и об атрибутах пользователей. Интеграция Drupal с LDAP позволяет пользователям входить в систему с учётными данными из каталога, а также автоматически создавать учётные записи Drupal и назначать роли на основе групп каталога. LDAP часто выступает в роли уровня, лежащего за протоколом SSO, а не заменяет его собой, и особенно распространён там, где учебное заведение работает на стеке Microsoft.
CAS
CAS (Central Authentication Service) — это протокол SSO с открытым исходным кодом, зародившийся в Йельском университете и по-прежнему широко используемый в системе высшего образования. Он был разработан специально для решения задачи SSO для веб-приложений и прекрасно уживается с такими хранилищами данных авторизации, как LDAP. В Drupal интеграция с CAS перенаправляет пользователей на центральный сервер CAS учебного заведения для аутентификации, а затем возвращает их на сайт уже вошедшими в систему, при этом роли могут назначаться на основе ответа CAS. Для университетов, у которых уже развёрнут CAS в масштабах всего кампуса, подключение к нему Drupal — естественное решение.
Какой протокол должен выбрать университет?
На практике выбор обычно диктуется тем, что учебное заведение уже использует — Drupal подключается к существующему IdP, а не наоборот. В таблице ниже приведена сводка, когда подходит тот или иной вариант.
| Подход | Что это такое | Оптимально для |
|---|---|---|
| SAML | Открытый стандарт федеративной аутентификации; максимально широкая совместимость. | Подключение к Entra ID, Okta, ADFS или любому другому IdP на базе SAML. |
| Shibboleth | Академическая реализация SAML; стандарт для исследовательских федераций. | Учебные заведения, входящие в национальную или международную академическую федерацию. |
| LDAP | Протокол работы с каталогами; базовый источник идентификационных данных пользователя. | Среды на базе Microsoft Active Directory; предоставление ролей. |
| CAS | Ориентированный на веб протокол SSO с открытым исходным кодом, распространённый в кампусах. | Учебные заведения с уже существующим сервером CAS в масштабах кампуса. |
Практическое правило простое: определите поставщика удостоверений, который ваше учебное заведение уже использует, а затем выберите ту интеграцию Drupal, которая способна с ним «общаться». Университет, входящий в академическую федерацию, подключает Drupal к Shibboleth; учебное заведение, стандартизированное на решениях Microsoft, подключается через SAML к Entra ID или через LDAP к Active Directory; учебное заведение, использующее серверы CAS в кампусе, подключается к CAS. Такой выбор редко делается «с чистого листа» — правильный ответ, как правило, определяется уже существующей инфраструктурой идентификации.
Как SSO работает на стороне Drupal
На стороне Drupal SSO обрабатывается через сторонние (contributed) модули, а не через ядро системы, и для каждого протокола существует зрелая экосистема. Независимо от используемого модуля, интеграция берёт на себя несколько ключевых задач: перенаправляет неаутентифицированных пользователей на IdP, принимает и проверяет ответ аутентификации, а также сопоставляет атрибуты, возвращаемые IdP, с учётной записью Drupal.
Здесь стоит разобраться в концепции предоставления учётных записей «точно в срок» (just-in-time, JIT). Вместо того чтобы заранее создавать учётную запись Drupal для каждого потенциального пользователя, JIT-предоставление автоматически создаёт учётную запись при первой успешной аутентификации пользователя через IdP, заполняя её атрибутами, которые предоставляет IdP, — именем, электронной почтой и ролью. Именно это позволяет SSO масштабироваться на весь университет: ни одному администратору не нужно вручную создавать тысячи учётных записей, а назначение ролей может автоматически управляться на основе членства в группах, о котором сообщает IdP. Для учебных заведений, оценивающих конкретные модули, официальные страницы проектов на Drupal.org для SimpleSAMLphp Authentication, LDAP и CAS документируют текущие поддерживаемые варианты.
Управление идентификацией: то, что упускает большинство руководств
Большинство руководств по SSO заканчиваются, как только вход в систему заработал. Но для университета, работающего с конфиденциальными данными студентов и сотрудников, более сложные и важные вопросы касаются управления: у кого есть доступ, как этот доступ отзывается и где на самом деле «живёт» идентификационная информация. Именно здесь грамотно продуманная интеграция отличается от просто работающей.
Центральный принцип заключается в том, что Drupal не должен вести собственный отдельный пул учётных записей пользователей параллельно с институциональным поставщиком удостоверений. Когда локальные учётные записи Drupal существуют независимо, они постепенно расходятся с реальным положением дел: их не отключают, когда кто-то уходит, и со временем на них накапливаются слабые пароли. Рекомендуемая практика заключается в том, чтобы отключить локальную аутентификацию по паролю для всех, кроме единственной «аварийной» учётной записи администратора (break-glass), направлять всю аутентификацию через IdP и наследовать многофакторную аутентификацию, политику паролей и жизненный цикл учётных записей учебного заведения от этого вышестоящего источника. Другими словами, единственным источником достоверной информации о том, кто может войти в систему, становится система идентификации учебного заведения, а не Drupal.
Такой подход даёт конкретное преимущество с точки зрения безопасности: возможность отзыва доступа (деprovisioning). Когда студент заканчивает обучение или сотрудник уходит, отключение его центральной учётной записи мгновенно закрывает доступ к Drupal вместе со всем остальным, не оставляя после себя «осиротевших» локальных логинов. Для учебного заведения, ответственного за защиту данных, такой единый централизованный «выключатель» гораздо безопаснее, чем попытки отследить отдельные учётные записи в каждой системе.
Университетские сценарии: мультисайтовость, жизненный цикл и выпускники
SSO в университетском контексте порождает несколько сценариев, с которыми никогда не сталкивается отдельный корпоративный сайт:
- Единый вход для нескольких сайтов (мультисайтовость): Крупные университеты управляют множеством сайтов — основным сайтом плюс отдельными сайтами для факультетов, кафедр и научно-исследовательских центров. SSO позволяет пользователю войти в систему один раз и беспрепятственно перемещаться между всеми ними, при этом аутентификация остаётся централизованной. Это естественным образом сочетается с мультисайтовой архитектурой Drupal, где множеством сайтов управляют из одного места.
- Жизненный цикл идентификации: Отношения человека с университетом со временем меняются — абитуриент, студент, выпускник, а иногда и сотрудник, — и вместе с этим меняются его потребности в доступе. Управление ролями Drupal на основе атрибутов IdP означает, что доступ может автоматически следовать этому жизненному циклу, а не корректироваться вручную при каждом переходе.
- Различные категории пользователей: Студентам, преподавателям, сотрудникам и выпускникам зачастую требуются разные уровни доступа к разным системам. Поскольку IdP сообщает о членстве в группах, Drupal может автоматически сопоставлять каждую категорию пользователей с соответствующей ролью, поддерживая соответствие прав доступа реальному статусу пользователя.
Именно эти сценарии объясняют, почему интеграция идентификации является неотъемлемой частью построения университетской платформы, а не второстепенным дополнением. Они также связаны с более широким набором академических интеграций, которые обычно нужны сайту на Drupal, — в том числе с обучающей платформой, о которой мы рассказываем в нашем руководстве по интеграции Moodle и Drupal.
Распространённые ошибки в SSO и как их избежать
- Использование локальных учётных записей наряду с IdP: Самый распространённый провал в управлении. Независимые учётные записи Drupal расходятся с реальным положением дел, не отзываются и накапливают слабые пароли. Направляйте аутентификацию через IdP и оставляйте локально только одну «аварийную» учётную запись администратора.
- Забыть про «аварийную» учётную запись: Если каждый вход в систему зависит от IdP, а IdP становится недоступен, никто не сможет войти — даже администраторы. Единственная надёжно защищённая локальная аварийная учётная запись предотвращает полную блокировку доступа.
- Небрежное сопоставление ролей: Автоматическое предоставление повышенных ролей Drupal на основе атрибутов IdP может непреднамеренно выдать административный доступ. Сопоставляйте каждый атрибут с минимально необходимым уровнем привилегий и относитесь к административным ролям с повышенным вниманием.
- Игнорирование отзыва доступа: Сосредоточение внимания только на том, чтобы вход в систему работал, оставляет без ответа более важный вопрос — как этот доступ отзывается. Продумывайте систему на случай, когда кто-то уходит, а не только на момент, когда он приходит.
- Выбор протокола в отрыве от контекста: Выбор технологии SSO без учёта того, что уже использует учебное заведение, приводит к излишней сложности. Отталкивайтесь от уже существующего поставщика удостоверений и подключайтесь к нему.
- Пренебрежение сопоставлением атрибутов: Если атрибуты IdP неправильно сопоставлены с полями и ролями Drupal, пользователи смогут войти в систему, но получат неверные права доступа. Проверяйте сопоставление атрибутов так же тщательно, как и сам процесс входа в систему.
При правильной реализации интеграция SSO превращает сайт на Drupal в бесшовную, безопасную часть цифровой экосистемы университета — единую идентификационную запись, централизованно управляемую и охватывающую все подключённые системы. Это фундаментальная возможность для любого учебного заведения, использующего Drupal в промышленных масштабах, и часть более широкого набора академических интеграций, рассмотренных в нашем обзоре Drupal в сфере образования.
Часто задаваемые вопросы о SSO в Drupal
Хранит ли Drupal пароли при включённом SSO?
Нет — в этом и заключается основное преимущество SSO с точки зрения безопасности. Когда аутентификация делегируется поставщику удостоверений, учётные данные пользователя проверяются IdP и никогда не хранятся в Drupal. Рекомендуемая конфигурация полностью отключает локальную аутентификацию по паролю, за исключением единственной «аварийной» учётной записи администратора, сохраняемой на случай чрезвычайных ситуаций. Это означает, что пароли, политика паролей и многофакторная аутентификация полностью находятся в центральной системе идентификации учебного заведения, а Drupal просто доверяет её проверенному ответу.
Может ли Drupal одновременно использовать несколько поставщиков удостоверений?
Да, в зависимости от используемых модулей Drupal можно настроить для работы с несколькими источниками аутентификации. Распространённый пример — учебное заведение, которое аутентифицирует студентов через одну систему, а сотрудников — через другую, или сохраняет SAML для большинства пользователей, оставляя ограниченный локальный вариант для определённой группы. С каждым дополнительным источником конфигурация усложняется, поэтому практический совет — поддерживать только тех поставщиков удостоверений, для которых существует реальная необходимость, и держать настройку максимально простой в той мере, в какой это позволяют реальные требования учебного заведения.
В чём разница между аутентификацией и предоставлением учётных записей?
Аутентификация — это проверка того, кем является пользователь, то есть подтверждение его учётных данных у поставщика удостоверений. Предоставление учётных записей (provisioning) — это создание и поддержание учётной записи и атрибутов пользователя в Drupal. SSO отвечает за аутентификацию; предоставление «точно в срок» (JIT) отвечает за последующее создание учётной записи, автоматически формируя учётную запись Drupal при первом входе в систему и заполняя её атрибутами, полученными от IdP. Они работают в связке: аутентификация подтверждает личность, а предоставление учётной записи даёт этой личности место и роль внутри Drupal.
Что лучше для университета — SAML или CAS?
Ни один из вариантов не является универсально лучшим — всё зависит от того, что уже использует ваше учебное заведение. SAML, включая его академическую реализацию Shibboleth, — правильный выбор для учебных заведений, входящих в исследовательские федерации или стандартизированных на платформах идентификации, таких как Entra ID или Okta. CAS отлично подходит для университетов, которые уже используют сервер CAS в масштабах кампуса. Решение должно опираться на существующую инфраструктуру идентификации, а не на абстрактный рейтинг: подключите Drupal к системе, которой ваше учебное заведение уже доверяет, и пусть именно это определит выбор протокола.