Упростите интеграцию SAML приложений для разработчиков

Единый вход (SSO) важен для современных приложений, и SAML обеспечивает безопасную, удобную аутентификацию в бизнес-системах идентификации. Это руководство упрощает SAML для разработчиков и дизайнеров с помощью четких шагов и практичных примеров, которые помогут вам эффективно реализовать его.

Что такое SAML SSO и SAML приложения?#

Язык разметки утверждений безопасности (SAML) — это стандарт на основе XML, используемый для обмена данными аутентификации и авторизации между двумя ключевыми игроками: Поставщиком Аутентификации (IdP) и Поставщиком Услуг (SP). Это обычное решение для Единого входа (SSO) в организациях, которое облегчает жизнь пользователям, позволяя им один раз войти в систему и получить доступ к нескольким приложениям.

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

• Пример: Представьте, что вы работаете в большой компании, которая использует Microsoft Azure AD для управления учетными записями сотрудников. Когда вы хотите войти в Salesforce, Azure AD действует как IdP. Он проверяет ваши учетные данные и сообщает Salesforce, что вы авторизованы для использования.

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

• Пример: Продолжая наш предыдущий сценарий, Salesforce является SP. Он рассчитывает на Microsoft Azure AD (IdP), чтобы подтвердить вашу личность. Как только Azure AD поручится за вас, Salesforce дает вам доступ.

Когда говорят о «SAML приложении», обычно имеют в виду SP.

С помощью протокола SAML вы можете настроить свою службу как IdP для поддержки интеграции приложений (например, Azure Ad / Google Workspace); или как SP (например, Salesforce / Slack), чтобы поддерживать SSO для пользователей.

SAML утверждение — это сердце протокола SAML. Это цифровая «записка», созданная IdP и отправленная в SP, в которой говорится: «Я подтвердил личность этого пользователя». Далее мы рассмотрим, как работает этот процесс для IdP и SP.

Когда действовать как Поставщик Аутентификации SAML#

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

Вот типичный рабочий процесс SAML SSO для IdP:

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

Когда действовать как Поставщик Услуг SAML#

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

Вот рабочий процесс для SSO, инициированного SP:

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

Ключевые параметры в SAML SSO#

Для успешной интеграции SAML SSO, как IdP, так и SP должны обмениваться определенными параметрами. Вот основные из них:

Параметры от IdP#

1. IdP Entity ID: Уникальный идентификатор IdP в сообщениях SAML, как цифровое имя.
2. SSO URL: Конечная точка для входа (URL), куда SP перенаправляет пользователей для аутентификации.
3. Сертификат X.509: Открытый ключ, используемый для подписи SAML утверждения, обеспечивающий его безопасность. Это «печать», подтверждающая подлинность.

Совет: Если ваш IdP предоставляет URL метаданных SAML, все становится проще. Этот URL содержит всю необходимую информацию (например, сертификаты, URL-адреса SSO и IdP Entity ID) в одном месте. Это минимизирует риск ошибок при ручном копировании и вставке и устраняет необходимость в обновлении файлов сертификатов вручную.

Параметры от SP#

1. SP Entity ID: Уникальный идентификатор SP, аналогичный IdP Entity ID.
2. URL службы потребления утверждений (ACS): Это конечная точка SP, где SP ожидает получить SAML утверждение от IdP.
3. RelayState (Необязательно): Используется для передачи данных во время процесса SAML, таких как URL, который пользователь изначально пытался посетить.

Отображение атрибутов SAML и шифрование#

1. Формат NameID: Определяет формат идентификатора пользователя (например, адрес электронной почты или имя пользователя).
2. Атрибуты SAML: Это дополнительные данные о пользователе, такие как роли, электронная почта или отдел, которые IdP отправляет в SP.
   • Пример: Если SAML утверждение, подписанное IdP, включает email ([email protected]), role (администратор) и department (инженерный). SP может использовать role для назначения административных привилегий или department для группировки пользователя в нужной команде. Таким образом, чтобы получить эти важные данные о пользователе, и IdP, и SP должны решить, как отображать атрибуты. Например, IdP может определить термин «department» как team, в то время как SP ожидает его как group. Правильное отображение обеспечивает плавное взаимодействие.
3. Зашифрованные утверждения (необязательно): Чтобы защитить конфиденциальные данные аутентификации, SAML утверждения могут быть зашифрованы.
   • Роль IdP: Шифрует утверждение с использованием открытого ключа SP.
   • Роль SP: Расшифровывает утверждение своим закрытым ключом, чтобы прочитать данные пользователя.

К этому моменту вы должны иметь достаточную информацию для настройки SAML соединения. Чтобы интегрировать Salesforce (Поставщик Услуг) с Azure AD (Поставщик Аутентификации), выполните следующие шаги:

• Получите IdP Entity ID, SSO URL и сертификат от Azure AD и настройте их в Salesforce.
• Предоставьте SP Entity ID и ACS URL Salesforce в Azure AD.

Logto упрощает интеграцию SAML#

Logto может действовать как IdP или SP для поддержки SAML SSO для ваших приложений.

Использование Logto в качестве SAML IdP#

Logto позволяет другим приложениям полагаться на него для федеративной аутентификации идентичности и поддерживает аутентификацию с учетом нескольких факторов (MFA) для повышенной безопасности.

1. Создайте приложение Logto Перейдите в Logto Console > Applications и создайте новое SAML приложение.
2. Настройка параметров SAML Настройте приложение с помощью URL службы потребления утверждений (ACS) и SP Entity ID Поставщика Услуг (SP).
3. Предоставьте URL метаданных Logto предоставляет URL метаданных IdP, который SP могут использовать для автоматического получения необходимых сведений, таких как URL-адреса SSO и сертификаты.
4. Расширенная конфигурация (необязательно)
   • Вы можете создать несколько новых сертификатов с отпечатками и установить даты истечения, но только один сертификат может быть активен одновременно.
   • Измените формат Name ID в соответствии с вашими бизнес-требованиями.
   • Включите шифрование утверждений SAML путем копирования и вставки сертификата x509 из вашего поставщика услуг для шифрования утверждений.
5. Настройка атрибутов (необязательно) Легко настраивайте, как атрибуты пользователей передаются Поставщикам Услуг (SP).

Для получения подробных указаний посетите официальную документацию здесь: SAML App

Использование Logto в качестве SAML SP#

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

1. Создайте корпоративный коннектор Перейдите в Logto Console > Enterprise SSO и создайте новый корпоративный коннектор. Выберите SAML в качестве стандарта протокола.
2. Настройка параметров SAML Предоставьте либо URL метаданных либо файл XML метаданных от вашего IdP. Если метаданные недоступны, переключитесь на ручную настройку, введя IdP Entity ID, SSO URL и загрузив подписанный сертификат.
3. Поделитесь URL ACS и SP Entity ID Предоставьте URL ACS и SP Entity ID Logto вашему IdP, чтобы завершить настройку интеграции.
4. Отображение атрибутов (необязательно) Настройте отображение данных пользователя, таких как электронная почта или имена, чтобы обеспечить правильную передачу информации между IdP и Logto.
5. Добавить корпоративные электронные домены На вкладке «SSO Experience» для корпоративного коннектора добавьте один или несколько доменов электронной почты. Это гарантирует, что только пользователи с указанными доменами смогут аутентифицироваться через SSO.
6. Включить SSO, инициированное IdP (необязательно) Включите SSO, инициированное IdP, только если это требуется вашим корпоративным клиентам. Эта функция позволяет пользователям входить в ваши приложения непосредственно с панели идей IdP.

Для получения подробных указаний посетите официальную документацию здесь: Enterprise SSO documentation.

Напоследок#

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