Руководство по безопасности SAML

Введение#

Язык разметки утверждений безопасности (SAML) — это открытый стандарт для обмена данными аутентификации и авторизации между сторонами, в частности, между поставщиком удостоверений и поставщиком услуг. SAML — это основанный на XML язык разметки для утверждений безопасности, который используется для единого входа (SSO) и федерации идентичности. Он часто используется в корпоративных средах для целей аутентификации и авторизации.

Стандартный поток аутентификации SAML#

1. Пользователь запрашивает доступ к клиентскому приложению, которое действует как поставщик услуг (SP).
2. SP отправляет запрос аутентификации SAML SSO поставщику идентификаторов (IdP) и перенаправляет пользователя к IdP.
3. IdP запрашивает у пользователя учетные данные, если пользователь еще не прошел аутентификацию.
4. Пользователь вводит учетные данные, и IdP его аутентифицирует.
5. IdP отправляет утверждение в ответ SAML на SP, которое включает статус аутентификации и атрибуты пользователя. Затем IdP перенаправляет пользователя обратно к SP.
6. SP получает утверждение в ответ SAML, проверяет его и предоставляет пользователю доступ.

Факторы безопасности в SAML#

Идентификатор сущности SP#

Думайте о идентификаторе сущности SP как о уникальном значке для SP в контексте аутентификации SAML. Это похоже на отпечаток пальца, который помогает IdP распознавать SP в ходе их взаимодействий. Этот идентификатор является ключевой частью метаданных SP, которые делятся с IdP для формирования доверия и обеспечения безопасной связи.

Использование идентификатора сущности SP:

1. Регистрация метаданных: Атрибут EntityID является частью метаданных SP, которые делятся с IdP для установления доверительных отношений. Оно служит уникальным идентификатором для определения местоположения метаданных SP и получения необходимых конфигурационных данных для взаимодействий SAML.
2. Запрос аутентификации: Идентификатор сущности SP включается в запрос аутентификации SAML, отправляемый IdP, что четко идентифицирует запрашивающий SP. IdP использует эту информацию для проверки запроса и определения подходящего контекста аутентификации.
3. Аудитория утверждения: После успешной аутентификации пользователя идентификатор сущности SP включается в SAML утверждение как ограничение аудитории. Эта мера гарантирует, что утверждение предназначено исключительно для назначенного SP и не может быть неправомерно использовано другими SP.

Идентификатор сущности IdP#

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

Использование идентификатора сущности IdP:

1. Регистрация метаданных: Атрибут EntityID также включен в метаданные IdP, делясь с SP для установления доверительных отношений. Он служит уникальным идентификатором для определения местоположения метаданных IdP и получения необходимых конфигурационных данных для того, чтобы SP мог проверять ответы SAML.
2. Издатель утверждений: Когда IdP формирует утверждение SAML, он включает свой идентификатор сущности в качестве издателя. Этот атрибут указывает сущность, выпустившую утверждение, и помогает SP проверять его подлинность и целостность.

Состояние реле#

Состояние реле — это параметр, используемый в аутентификации SAML, который облегчает передачу информации о состоянии между SP и IdP. Он действует как мост между инициируемыми SP и IdP потоками SSO, сохраняя контекст пользователя и состояние сеанса в процессе аутентификации.

Использование состояния реле:

1. Поддержание контекста пользователя: Состояние реле позволяет SP передавать дополнительную информацию IdP в процессе аутентификации. Эта информация может включать состояние сеанса пользователя, контекст приложения или любые другие релевантные данные, которые необходимо сохранить в потоке SAML. Например, URL или идентификатор сеанса приложения, к которому пользователь обращался до аутентификации.
2. Предотвращение атак CSRF: Состояние реле важно для предотвращения атак межсайтовой подделки запросов (CSRF) в процессе аутентификации SAML. Включив уникальное и непредсказуемое значение состояния реле в запрос аутентификации, SP может убедиться в целостности ответа SAML и удостовериться, что он соответствует исходному запросу.

Подпись утверждения#

Подпись утверждения — это критическая функция безопасности в SAML, которая гарантирует целостность, подлинность и невозможность отказа от SAML-утверждений. Она включает в себя цифровую подпись SAML-утверждения с использованием закрытого ключа IdP, позволяя SP проверять происхождение утверждения и обнаруживать любую попытку подделки.

Как работает подпись утверждения:

1. Создание пары ключей: IdP генерирует пару открытого-закрытого ключа, где закрытый ключ используется для подписания SAML-утверждения, а открытый ключ делится с SP для проверки. Эта схема асимметричного шифрования гарантирует, что только IdP может подписать утверждение, в то время как SP может его проверить.
2. Общий сертификат: IdP предоставляет SP свой сертификат открытого ключа, который содержит открытый ключ, используемый для проверки подписи утверждения. Обычно этот сертификат будет частью метаданных IdP, или SP может получить его через безопасный процесс скачивания.
3. Подписание утверждения: После аутентификации пользователя IdP цифрово подписывает SAML-утверждение с использованием своего закрытого ключа. Эта подпись включена в утверждение вместе с сертификатом открытого ключа, позволяя SP проверить подлинность утверждения.
4. Проверка утверждения: Получив SAML-утверждение, SP использует открытый ключ IdP для проверки подписи утверждения. Если подпись действительна, SP может доверять утверждению и предоставить пользователю доступ.

Шифрование утверждения#

Помимо подписания, SAML также поддерживает шифрование утверждений для защиты конфиденциальных пользовательских атрибутов и данных, передаваемых между IdP и SP. Шифруя утверждение, IdP гарантирует, что только предполагаемый получатель (SP) сможет расшифровать и получить доступ к содержимому утверждения, обеспечивая конфиденциальность пользователя и конфиденциальность данных. Шифрование утверждений является необязательной функцией безопасности в SAML, которая может быть использована для усиления защиты данных.

Использование шифрования утверждений:

1. Защита конфиденциальных атрибутов: Шифрование утверждений особенно полезно для защиты конфиденциальных пользовательских атрибутов, таких как информация о личности (PII), финансовые данные или медицинские записи. Шифруя эти атрибуты в утверждении, IdP предотвращает несанкционированный доступ и обеспечивает конфиденциальность данных.

Как работает шифрование утверждений:

1. Обмен ключами: IdP и SP устанавливают безопасный механизм обмена ключами для распространения ключей шифрования, которые защищают SAML-утверждение. Это может включать использование симметричных ключей шифрования или схем шифрования с открытым ключом, в зависимости от алгоритма шифрования и стратегии управления ключами.
2. Шифрование атрибутов: После генерации SAML-утверждения IdP шифрует конфиденциальные пользовательские атрибуты с использованием общего ключа шифрования. Зашифрованные атрибуты встраиваются в утверждение, обеспечивая, что только SP сможет расшифровать и получить доступ к данным.
3. Расшифровка утверждения: Получив зашифрованное утверждение, SP расшифровывает защищенные атрибуты с использованием общего ключа шифрования. Этот процесс позволяет SP получить доступ к конфиденциальным данным пользователя безопасно и обрабатывать их по мере необходимости.

Методы связывания#

Методы связывания SAML определяют, как сообщения SAML передаются между SP и IdP через различные протоколы связи. Они указывают кодирование, транспорт и механизмы безопасности, используемые для обмена SAML-утверждениями и запросами, обеспечивая безопасное и надежное соединение между вовлеченными сторонами.

И SP, и IdP укажут, какие методы связывания они поддерживают, в своих метаданных, позволяя им согласовывать подходящий метод для взаимодействий SAML. Выбор метода связывания зависит от таких факторов, как размер сообщения, требования к безопасности и характеристики канала связи.

Методы связывания SAML:

1. HTTP Redirect: Сообщения SAML кодируются как параметры URL и передаются через перенаправление HTTP. Эта схема подходит для сценариев, где размер сообщения ограничен, а канал связи не является безопасным.
2. HTTP POST: Сообщения SAML кодируются как параметры формы и передаются через запросы HTTP POST. Этот метод используется, когда размер сообщения превышает лимит длины URL или когда требуются дополнительные меры безопасности.
3. Artifact: Сообщения SAML передаются с использованием токенов короткого срока действия, называемых артефактами, которые обмениваются через безопасный обратный канал между SP и IdP. Этот метод связывания подходит для сценариев, где конфиденциальность и целостность сообщений являются критическими, а канал связи безопасным.

Наиболее распространенные методы связывания:

• Запрос аутентификации: Запрос аутентификации от SP к IdP обычно передается с использованием HTTP Redirect благодаря его простоте и эффективности. SP кодирует запрос SAML как параметры URL и перенаправляет браузер пользователя к IdP для аутентификации. Это известно как инициированный SP поток SSO.
• Ответ утверждения: Утверждение ответа SAML от IdP к SP обычно передается с использованием метода связывания HTTP POST. IdP кодирует SAML утверждение как параметры формы и отправляет его обратно SP для проверки. Это обеспечивает безопасную передачу утверждения без раскрытия конфиденциальных данных в URL. Кроме того, метод связывания HTTP POST может обрабатывать большие размеры сообщений по сравнению с методом связывания HTTP Redirect.

Элементы безопасности и соображения в утверждениях SAML#

Издатель#

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

Подпись#

Элемент подписи в утверждении SAML содержит цифровую подпись, созданную IdP для обеспечения его целостности и подлинности. Подпись создается с использованием закрытого ключа IdP и включается в утверждение вместе с сертификатом открытого ключа для проверки SP. Проверяя подпись, SP может удостовериться, что утверждение не было подделано и исходит от ожидаемого IdP.

Условия#

Элемент условий в утверждении SAML определяет ограничения и ограничения, которые применяются к его действительности и использованию. Он включает условия, такие как период действительности утверждения, ограничения аудитории и другие контекстные ограничения, которые SP должен выполнить при обработке этого утверждения.

Заявление об аутентификации#

Заявление об аутентификации (AuthnStatement) является ключевым компонентом утверждения SAML, который предоставляет информацию о статусе и контексте аутентификации пользователя. Он включает детали, такие как использованный метод аутентификации, время аутентификации и любую релевантную информацию о контексте аутентификации, позволяя SP принимать информированные решения о контроле доступа на основе аутентификационного состояния пользователя.

Атрибуты заявления об аутентификации:

1. AuthenticationContext: Описывает метод и контекст аутентификации пользователя, такие как имя пользователя-пароль, многофакторная аутентификация или единый вход. Этот атрибут помогает SP оценивать силу и надежность процесса аутентификации и определять соответствующие механизмы контроля доступа.
2. AuthenticationInstant: Указывает время, когда пользователь был аутентифицирован IdP. Эта метка времени важна для проверки свежести аутентификации и предотвращения атак повторного воспроизведения или захвата сеанса.
3. SessionNotOnOrAfter: Определяет время истечения сеанса пользователя, после которого пользователь должен вновь пройти аутентификацию для доступа к сервису. Этот атрибут помогает обеспечивать соблюдение политики управления сеансами и уменьшать риск несанкционированного доступа.

Лучшие практики для безопасности SAML#

1. Используйте безопасные методы связывания: Выбирайте подходящие методы связывания SAML на основе требований к безопасности и характеристик канала связи. Используйте HTTP POST для передачи конфиденциальных данных и HTTP Redirect для простых запросов.
2. Проверяйте подписи утверждений: Проверяйте цифровые подписи утверждений SAML для обеспечения их целостности и аутентичности. Используйте сертификат открытого ключа IdP для проверки подписи и обнаружения попыток подделки.
3. Внедряйте ограничения аудитории: Включайте ограничения аудитории в SAML утверждения, чтобы ограничить область действия утверждения до предназначенного SP. Это предотвращает атаки повторного воспроизведения утверждений и несанкционированный доступ со стороны других поставщиков услуг.
4. Обеспечьте безопасный обмен метаданными: Защищайте обмен метаданными SP и IdP для предотвращения их подделки и спуфинга. Используйте безопасные каналы и механизмы для безопасного обмена метаданными.
5. Используйте безопасное управление состоянием реле: Используйте уникальные и непредсказуемые значения состояния реле для предотвращения атак CSRF в процессе аутентификации SAML. Проверьте состояние реле для обеспечения его целостности и подлинности.
6. Внедряйте управление сеансами: Определяйте политики истечения сеанса и обеспечивайте отсечку сеансов для уменьшения риска захвата сеанса и несанкционированного доступа. Используйте атрибуты, связанные с сеансом, в SAML утверждениях для безопасного управления пользовательскими сеансами.
7. Шифруйте конфиденциальные атрибуты: При необходимости шифруйте конфиденциальные пользовательские атрибуты в SAML утверждениях для защиты конфиденциальности и конфиденциальности данных. Используйте безопасные алгоритмы шифрования и практики управления ключами для защиты конфиденциальных данных.

Альтернативы SAML#

Хотя SAML остается широко распространённым стандартом для единого входа и федерации идентификации, предлагая мощный набор функций и механизмов безопасности, его возраст может вызвать проблемы с удовлетворением меняющихся требований к безопасности и удобству современных приложений. По сравнению с более современным OAuth 2.0 на основе OpenID Connect (OIDC) SAML, как правило, является более сложным и не обладает некоторыми улучшенными функциями безопасности, предлагаемыми OIDC. Например, многоуровневая авторизация кода запроса OIDC предлагает более безопасный подход по сравнению с относительно простым потоком обмена утверждениями SAML. Для организаций, стремящихся внедрить более современное и гибкое решение для федерации идентификации, OIDC может быть жизнеспособной альтернативой SAML.