Авторизация SAML и контроль доступа

Инструкции и методология по определению политики доступа и управлению SAML в вашей организации.

SAML позволяет организациям управлять аутентификацией и правами доступа пользователей Tulip с помощью существующего поставщика идентификации (IdP). В данном руководстве подробно описаны доступные варианты реализации интеграции с IdP корпоративного уровня через протокол SAML.

Подготовительные работы

• Ознакомьтесь с ролями пользователей Tulip
• Сгруппируйте предполагаемых пользователей Tulip по ролям, чтобы быть готовыми обновить атрибут SAML, указав их роль в Tulip
• Определите, кто в вашей организации будет настраивать IdP и учётную запись Tulip

Настройка IdP

Когда ваш экземпляр Tulip настроен на использование SAML для входа, Tulip поддерживает связь между пользователями в Tulip и пользователями в вашем корпоративном поставщике идентификации (IdP). У каждого пользователя, имеющего учетную запись в IdP, должна быть не более одной учетной записи в данном экземпляре Tulip. Tulip поддерживает эту связь с помощью специфического для SAML понятия, называемого «NameID». NameID — это непрозрачный тип идентификатора, предоставляемый в рамках аутентификации SAML и определяемый IdP.

Поскольку NameID используется для поддержания этой связи, Tulip предполагает, что NameID должны быть стабильными, то есть NameID, получаемый Tulip для конкретного пользователя IdP, не должен изменяться в течение всего срока существования учетной записи пользователя. Если NameID пользователя все же изменится, связь будет нарушена, и при входе в систему могут возникать ошибки.

Tulip настоятельно рекомендует настроить ваш IdP таким образом, чтобы он предоставлял NameID, который не будет меняться со временем. По этой причине Tulip не рекомендует использовать имена или адреса электронной почты в качестве NameID, поскольку эти значения могут меняться со временем. Мы рекомендуем настроить ваш IdP на использование внутренних идентификаторов объектов или имен учетных записей, которые гарантированно никогда не изменятся.

Обратите внимание, что NameID не обязательно должны быть удобочитаемыми или узнаваемыми для человека (более того, с точки зрения безопасности обычно лучше использовать неузнаваемые значения в качестве NameID).

При настройке вашего IdP мы рекомендуем установить для параметра «Формат NameID» значение «Постоянный», что указывает Tulip на то, что значение должно оставаться неизменным в течение всего срока существования учетной записи пользователя.

При сопоставлении исходного значения атрибута NameID сопоставьте его значению, которое, как известно, является неизменяемым, например «идентификатору объекта» или «имени субъекта пользователя».

Microsoft Entra

Клиентам, использующим Microsoft Entra в качестве IdP, следует выполнить следующие инструкции для настройки приложения Tulip на использование постоянных NameID:

1. В Entra начните с корпоративного приложения, связанного с вашим экземпляром Tulip.
2. В левом меню навигации нажмите «Единый вход» в группе «Управление».
3. Отредактируйте раздел «Attributes & Claims» (Атрибуты и претензии).
4. В разделе «Required Claims» (Обязательные претензии) щелкните строку с претензией «Unique User Identifier (Name ID)» (Уникальный идентификатор пользователя (Name ID)).
5. Убедитесь, что для параметра «Формат идентификатора имени» установлено значение «Постоянный». Установите для параметра «Источник» значение «Атрибут» и выберите атрибут, который будет оставаться неизменным на протяжении всего срока существования учетной записи пользователя. Хорошими вариантами являются user.userprincipalname и user.objectid.

Параметры конфигурации SAML и Tulip

Режимы управления

Режим управления Tulip означает, что роль пользователя в Tulip и его рабочая область берутся из сопоставления атрибутов SAML только при первом входе в Tulip.

Пользователи, деактивированные в Tulip, не смогут войти в систему.

Режим управления IdP означает, что роль и рабочая область пользователя в Tulip будут обновляться из IdP при каждом входе в систему.

Сопоставление ролей по умолчанию (только в режиме управления Tulip)

При первом входе всем пользователям присваивается уровень доступа по умолчанию («Просмотрщик» с доступом к проигрывателю). Затем владельцу учетной записи необходимо вручную настроить роль на соответствующий уровень в Tulip.

Рабочие пространства

Узнайте больше о рабочих пространствах

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

Настраиваемое сопоставление рабочих пространств по SAML

:::(Информация) (Несколько рабочих пространств)
Обратите внимание: привязка пользователей к нескольким рабочим пространствам возможна только в режиме управления « Tulip ».

В режиме управления IdP каждый пользователь может быть членом только одного рабочего пространства.
:::

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

Сопоставление рабочих пространств по умолчанию

При первом входе в систему всем пользователям предоставляется доступ к рабочей области по умолчанию, выбранной вами. Затем владелец учетной записи может настроить доступ к рабочей области.

Группы пользователей

Вы можете сопоставлять пользователей с функцией «Группы пользователей»{target=_blank} Tulip во всех конфигурациях SAML.

Группы пользователей существуют на уровне учетной записи. Как только пользователь сопоставлен с группой пользователей, он становится членом этой группы во всех рабочих пространствах.

После включения опции «Группы пользователей» вы сможете сопоставлять пользователей из вашего поставщика идентификации (IdP) с группами пользователей в Tulip на основе значения атрибута в SAML.

После этого вы сможете указать до 100 атрибутов SAML и сопоставить значения каждого из них с группой пользователей. Таким образом, один пользователь может быть отнесён к нескольким группам пользователей.

Сопоставление групп пользователей и поведение в режиме управления

Поведение членства в группах пользователей зависит от настройки режима управления.

• Режим управления Tulip: группы, сопоставленные пользователю по SAML, применяются только при первом входе в систему. После этого членством в группах можно управлять в Tulip, и любые изменения, внесенные вручную, сохраняются при последующих входах в систему.
• Режим управления IdP: полное членство пользователя в группах пересчитывается на основе его текущих атрибутов SAML при каждом входе в систему. Tulip назначает пользователю те группы, которые вычисляются в результате сопоставления, и удаляет его из всех групп, не охваченных сопоставлением, включая группы, которые были назначены вручную в Tulip.

Параметры аутентификации

Если вы хотите использовать ключи FIDO для аутентификации пользователей, вам необходимо «Отключить сопоставление методов аутентификации».

Класс контекста аутентификации

Класс контекста аутентификации — это указанный метод, с помощью которого пользователи проходят аутентификацию.

Если эта опция включена, пользователи смогут проходить аутентификацию только с помощью указанного метода.

Если эта опция отключена, выбор метода аутентификации полностью перекладывается на поставщика идентификации.

Принудительная аутентификация

Tulip использует параметр SAML forceAuthn для управления тем, должны ли пользователи проходить повторную аутентификацию у своего поставщика идентификации (IdP) при каждом входе в систему или можно ли повторно использовать существующий сеанс SAML на уровне ОС. Tulip не использует параметр isPassive. В данном случае под существующим сеансом понимается сеанс SAML на уровне ОС (например, сеанс Windows, привязанный к вашему поставщику идентификации), а не сеанс, специфичный для Tulip.

Принудительная аутентификация ВКЛЮЧЕНА (по умолчанию): Tulip отправляет forceAuthn=true, что требует от пользователя активной аутентификации у своего IdP при каждом входе в систему, независимо от наличия какого-либо существующего сеанса SAML на уровне ОС. Этот параметр гарантирует, что пользователи не смогут обойти повторную аутентификацию.

Принудительная аутентификация ВЫКЛ: Tulip отправляет forceAuthn=false. Если у пользователя уже есть активная сессия SAML на уровне ОС, распознаваемая поставщиком идентификации (IdP), он будет автоматически авторизован в Tulip без повторного ввода учетных данных.

Настройка

Дополнительные настройки для входа пользователя.

Название кнопки входа — настройте текст на кнопке входа по SAML на страницах входа в Tulip.

Пользовательский адрес электронной почты службы поддержки — Укажите собственный адрес электронной почты, который будет отображаться пользователям при возникновении ошибки входа по SAML. Это может направить пользователей в вашу внутреннюю службу ИТ-поддержки. Если поле оставить пустым, будет использоваться адрес электронной почты службы поддержки по умолчанию «support@tulip.co».

Настольный плеер: браузер по умолчанию ОС для аутентификации

Если для входа с помощью SSO или авторизации через OAuth-коннектор требуется интеграция, доступная только через браузер по умолчанию, Tulip Player можно настроить так, чтобы процессы аутентификации открывались в браузере по умолчанию ОС, а не во встроенном окне.

Требования к версии

Для аутентификации в браузере по умолчанию ОС необходимо соблюдать следующие требования к версии Tulip:* Desktop Player 2.8 или выше* Factory release 318 или выше

Поведение функции

Данное поведение применимо как к входу в Desktop Player через SSO, так и к авторизации OAuth-коннекторов в приложениях Tulip. В обоих случаях, когда пользователь инициирует аутентификацию, открывается системный браузер по умолчанию для выполнения следующего процесса:

1. Системный браузер запускается и переходит на страницу входа в систему поставщика идентификации (IdP) вашей организации.
2. Пользователь завершает вход в систему (вводит учетные данные, проходит многофакторную аутентификацию (MFA) и т. д.) в браузере точно так же, как он делал бы это в веб-интерфейсе.
3. По завершении аутентификации на странице браузера отображается следующее сообщение: «Готово! Вы можете закрыть это окно».
4. Окно браузера остаётся открытым. Оно не закрывается автоматически. Пользователю необходимо закрыть его вручную.
5. Tulip Desktop Player определяет, что вход завершен, и продолжает работу в обычном режиме.

Ожидаемые запросы на разрешения

В зависимости от операционной системы и настроек браузера пользователи могут увидеть один или два запроса на предоставление прав:

1. Разрешение для Desktop Player на прохождение брандмауэра / локального сервера (на уровне ОС)

При запуске аутентификации Desktop Player создает временный локальный сервер для получения ответа на аутентификацию. В зависимости от ОС и настроек безопасности может появиться запрос системного брандмауэра или сетевого доступа с вопросом, разрешено ли Desktop Player принимать входящие соединения.

• Необходимое действие: разрешить соединение. Это ожидаемое поведение, необходимое для завершения входа в систему.
• В зависимости от настроек ОС этот запрос может появляться только при первом запуске или каждый раз.

2. Разрешение на доступ к локальной сети в браузере (на уровне браузера)

После того как пользователь завершит вход в систему через своего поставщика идентификации, страница завершения аутентификации браузера отправляет результат обратно в Desktop Player, направляя запрос на локальный сервер, описанный выше. В некоторых браузерах отображается запрос на разрешение, в котором спрашивается, разрешено ли странице получать доступ к устройствам в локальной сети.

• Необходимое действие: разрешить доступ. Это безопасный и ожидаемый этап процесса аутентификации.
• Запрос отправляется только на localhost и содержит исключительно зашифрованный ответ на аутентификацию. На данном этапе не передаются никакие конфиденциальные учетные данные.

Сравнение различий с точки зрения пользователя

В приведенной ниже таблице сравниваются особенности поведения стандартной аутентификации и аутентификации, реализованной через браузер ОС:

Пример: создание групп доступа в вашем IdP

Следующий пример поможет вам понять, как все различные параметры в настройках SAML можно использовать вместе.

Создание стандартизированных ролей Tulip

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

Вы также можете использовать это поле «Роль» для определения сайтов, к которым у пользователя есть доступ, с помощью стандартной конвенции именования. Хотя поле «Роль» может быть просто заданной переменной, рекомендуется присвоить пользователю группы, специфичные для Tulip, в вашем IdP и сопоставить их с атрибутом.

Роль

Каждому пользователю назначается одна роль в одной рабочей среде.

Когда Tulip получает несколько допустимых ролей для пользователя, применяется следующая логика:

Если набор содержит какие-либо встроенные роли (Operator, Builder и т. д.), Tulip выбирает встроенную роль с наивысшим рангом на основе статической внутренней иерархии. Пользовательские роли всегда имеют более низкий ранг, чем все встроенные роли, поэтому они никогда не будут выбраны, если присутствует какая-либо встроенная роль.

Если набор содержит только пользовательские роли, Tulip выбирает первую пользовательскую роль, полученную в полезных данных SAML.

Узнайте больше о ролях пользователей в Tulip.

Сайт

Предположим, что у вашей организации есть два сайта, для каждого из которых существует свой домен Tulip Instance.

Каждый сайт можно обозначить по его местоположению (соответственно, Техас и Лондон).

Объединение сайта и роли

Мы можем объединить эти два свойства, чтобы создать матрицу групп для назначения пользователей. Мы рекомендуем организациям добавлять слово «Tulip» в начало или в конец значения, чтобы упростить фильтрацию.

Условная нотация: tulip-siteRole

Если Джейн Смит является руководителем филиала в Техасе, ее следует отнести к группе tulip-texasAccountOwner. Если Джейн Смит также требуется доступ для просмотра данных филиала в Лондоне, ее можно добавить в группу tulip-londonViewer.

Сделайте эти группы доступными в качестве атрибута для Tulip

В вашем IdP у Джейн должен быть атрибут tulip-role, в который будут сопоставлены все группы, членом которых она является и которые содержат префикс «tulip-».

Когда она входит в Tulip, атрибут «tulip-role» принимает два значения: «tulip-texasAccountOwner» и «tulip-londonViewer». Вы можете настроить сопоставление ролей для каждого « Tulip instance » индивидуально, чтобы она получала правильные разрешения в каждом экземпляре.

Глобальные роли

Вы также можете создать глобальные роли доступа, например роль «Viewer». Эти пользователи смогут входить в систему на каждом экземпляре Tulip instance с одинаковыми правами доступа. Рекомендуемый формат для этого:

tulip-globalViewer

Вам необходимо настроить это сопоставление ролей на каждом отдельном экземпляре на странице конфигурации SAML в «Настройках учётной записи», чтобы этот пользователь мог получить доступ к каждому экземпляру.

{{snippet.Нашли ли вы то, что искали?}}