Обзор единого входа
Обзор единого входа
Единый вход (SSO) - это механизм аутентификации сессии и пользователя, позволяющий использовать один набор учетных данных для доступа к нескольким приложениям предприятия независимо от платформы, технологии или домена. После входа в приложение, поддерживающее SSO, пользователь автоматически входит в любое другое приложение, на которое у него есть соответствующие разрешения. PTC рекомендует использовать SSO как метод аутентификации.
* 
Если приложение сконфигурировано для использования SSO, можно сконфигурировать многофакторную аутентификацию (MFA) с помощью поставщика удостоверений (IdP), если IdP поддерживает MFA. Приложения PTC не управляют MFA; MFA конфигурируется с помощью IdP.
Процесс обработки информации SSO состоит из обмена данными аутентификации и авторизации. Каждый из компонентов, перечисленных в таблице, играет роль в одном или обоих обменах:
Термин
Определение
Центральный сервер аутентификации (CAS)
Сторонний инструмент, который управляет аутентификацией и авторизацией пользователей в объединении SSO. Это позволяет пользователям получать доступ к данным с нескольких серверов ресурсов с помощью делегированной авторизации.
PTC поддерживает следующие центральные серверы аутентификации:
PingFederate
Microsoft Entra ID
Для ThingWorx 9.2.0 и более поздних версий, 9.1.4 и более поздних версий и 9.0.9 и более поздних версий
Для ThingWorx Navigate 9.5.0 и более поздних версий
Для Windchill 12.0.2.2 и более поздних версий
Azure AD B2C
Для ThingWorx 9.6.0 и более поздних версий.
AD FS
Для ThingWorx версий, 9.2.0 и более поздних версий, 9.1.4 и более поздних версий и 9.0.9 и более поздних версий
* 
При использовании Microsoft Entra ID и AD FS с ThingWorx каждая из этих систем действует и как CAS, и как IdP.
Открытая авторизация (OAuth)
OAuth является промышленным стандартом, который использует лексемы доступа, чтобы разрешить приложению выполнять проверку подлинности от имени пользователя в другом приложении и загружать данные, принадлежащие пользователю.
Инфраструктура PTC SSO использует OAuth 2.0.
Язык разметки утверждений безопасности (SAML)
SAML - это промышленный стандарт аутентификации на основе XML, который устраняет необходимость в специфичных для приложения паролях. В SAML для обмена данными аутентификации и авторизации между поставщиком удостоверений и поставщиком сервисов с установленными доверительными отношениями используются одноразовые цифровые лексемы с истекающим сроком действия.
В инфраструктуре SSO PTC используется SAML 2.0.
OpenID Connect (OIDC)
OpenID Connect (OIDC) - это слой реквизитов, построенный на основе платформы OAuth 2.0. Это позволяет приложениям сторонних производителей проверять реквизиты конечного пользователя и получать основную информацию о профиле пользователя. OIDC использует веб-лексемы JSON (JWT), которые можно получить с помощью процессов, соответствующих спецификациям OAuth 2.0.
Лексема доступа
Непрозрачная строка лексемы JWT, полученная с сервера авторизации, которую приложение предоставляет другому приложению для доступа к данным владельца ресурса.
Объединение
Сеть программных приложений на предприятии, настроенная на использование CAS для включения единого входа.
Поставщик удостоверений (IdP)
Сторонний инструмент, который управляет данными удостоверений пользователя. В системе управления пользователями или в Active Directory хранятся имена пользователей, пароли и другие учетные данные. CAS обращается к IdP при аутентификации пользователя.
* 
При использовании Microsoft Entra ID и AD FS с ThingWorx каждая из этих систем действует и как CAS, и как IdP.
Сервер ресурсов (RS)
Приложение в объединении SSO, которое содержит защищенные данные.
Поставщик сервисов (SP)
Веб-сервер, с которого пользователь обращается к информации. Для аутентификации пользователей в объединении SSO используется протокол SAML. Поставщик сервисов также запрашивает доступ к защищенным данным у поставщика ресурсов от имени аутентифицированного пользователя.
Контекстная область
Строковые значения, регистрируемые в CAS, SP и RP. Это обеспечивает дополнительное управление доступом для данных владельца ресурса, доступных в сервере ресурсов. Если поставщику сервисов предоставляется разрешение для контекстной области, связанной с защищенным ресурсом, данные становятся доступными для поставщика сервисов только в том случае, если он также предоставляет действительную лексему доступа.
Агент пользователя
Веб-браузер, на котором пользователь (владелец ресурса) получает доступ к информации. Агент пользователя действует от имени пользователя, чтобы выполнять запросы от поставщика сервисов и CAS.
Было ли это полезно?