saml-2.0 учебник
Начало работы с saml-2.0
Поиск…
замечания
SAML2.0 - это открытый стандарт, используемый для передачи данных аутентификации и авторизации между поставщиками услуг и поставщиками удостоверений.
Наиболее распространенным применением является SSO на базе веб-сайтов, где SAML - это то, что позволило пользователю войти в приложение с учетными данными из другой системы, не требуя, чтобы две системы напрямую соединялись друг с другом во время аутентификации.
Поток аутентификации SAML2.0
SAML определяет три ключевые роли:
Поставщик удостоверений (IdP)
Сторона, которая обеспечивает и поддерживает личность пользователей. Это может быть служба каталогов, такая как ADFS или пользовательское решение базы данных.
Поставщик услуг (SP)
Поставщик услуг - это фактический сервис, к которому пользователь пытается войти. Это может быть веб-сайт, приложение или любая служба, к которой пользователь должен войти в систему.
Руководитель / пользователь
Фактический пользователь, инициирующий запрос, или пытается получить доступ к ресурсу от поставщика услуг (SP).
Основным случаем использования SAML является веб-SSO , где процесс SAML ведется набором переадресаций в браузере пользователей, где пользователь действует как токен-носитель между IdP и SP.
Существует два потока для SSO с использованием SAML:
Идентификатор поставщика (IdP), инициированный
Пользователь регистрируется в IdP и затем перенаправляется в SP по выбору. Например, пользователь регистрируется в корпоративной интрасети и представлен всеми доступными приложениями.
Поставщик услуг (SP) Инициирован
Пользователь пытается войти в приложение, но перенаправляется в IdP для выполнения фактической проверки подлинности. Например, пользователь пытается войти в удаленное приложение SaaS , но перенаправляется на корпоративный IdP, чтобы пользователь мог войти с помощью своих корпоративных учетных данных в удаленное приложение.
Поток, инициируемый SP, визуализируется в основном благодаря рабочему процессу ниже:
Источник: Википедия
- Пользователь пытается получить доступ к ресурсу на конкретном приложении или веб-странице
- Пользователь указывает (-ы), что он пытается войти в систему, используя внешний IdP. SP будет генерировать утверждение SAML и будет передавать это (обычно через переменные POST или GET), пересылая вас в IdP
- Пользователь будет аутентифицирован против IdP
- Подписанное утверждение и токен генерируются IdP
- Подписанное утверждение и токен перенаправляются обратно (снова используя переменные POST или GET) в SP, и если успешный сеанс инициируется на SP
- и, кроме того, пользователь может запрашивать дополнительные ресурсы из SP, когда он имеет активный сеанс с SP (то есть через файлы cookie), поэтому ему не нужно аутентифицироваться с IdP по каждому запросу.
Инструменты отладки SAML
Со всеми запросами и утверждениями, идущими назад и вперед, может быть громоздко отлаживать проблемы с вашими утверждениями и утверждениями SAML.
Как и в SAML, основной принцип не требует прямого соединения между IdP и SP, браузер пользователя выступает в качестве носителя сообщений между ними. Из-за этого все сообщения, пусть и зашифрованные, проходят через ваш собственный браузер.
Используя различные инструменты отладки, вы можете видеть точную связь и запросы, сделанные и пересылаемые между IdP и SP.
Чтобы начать работу, вот несколько инструментов для различных браузеров, которые должны вас запустить:
Хром
Fire Fox
Используя, например, SAML Tracer вы можете видеть декодированные утверждения и запросы SAML в режиме реального времени во время тестирования и отладки