Конфигурирование центрального сервера аутентификации
Центральный сервер аутентификации (CAS) управляет взаимоотношениями доверия между продуктами PTC, участвующими в инфраструктуре SSO. CAS выступает в роли посредника между приложениями, выполняя авторизацию входа пользователей после аутентификации пользователя, а затем выдавая и проверяя лексемы доступа, которыми обмениваются поставщики сервисов и серверы ресурсов.
Ниже приведены некоторые общие советы, которые следует учитывать при развертывании CAS.
• Проверяйте максимальное время, в течение которого сессия входа пользователя в систему действительна, и решайте, должны ли эти значения использоваться в каждом из приложений, участвующих в решении SSO.
• Подтвердите, что системы работают в пределах приемлемого допуска расфазировки тактовых импульсов (на английском языке). Если один или несколько системных тактовых импульсов не синхронизированы с CAS и превышается заданное время допуска расфазировки тактовых импульсов в системе, то конфигурация будет вызывать ошибки и прекращать аутентификацию пользователей.
Продукты PTC с поддержкой SSO реализуют следующие два потока аутентификации с использованием платформы SSO и стандартных протоколов:
• Федеративная аутентификация
• Авторизация - делегированная авторизация с использованием типов предоставления OAuth
Федеративная аутентификация
Федеративная аутентификация - это процесс проверки запроса на вход пользователя в систему путем его сравнения с учетными данными, хранящимися в поставщике удостоверений.
В архитектуре SSO продукта PTC центральный сервер аутентификации (CAS) должен быть сконфигурирован для перенаправления запросов на вход пользователя в IdP организации. IdP проверяет подлинность учетных данных пользователя и создает утверждение, что пользователь был аутентифицирован. Аутентификация осуществляется с помощью SAML или OIDC в зависимости от протокола, поддерживаемого для продукта PTC (см. Поддерживаемые протоколы SSO для продуктов PTC) и конфигурации клиента.
После подтверждения аутентификации запрашивающему приложению отправляется утверждение, подтверждающее, что пользователь успешно прошел аутентификацию, и авторизуется вход пользователя. Во время этой транзакции ни CAS, ни приложение PTC не будут видеть учетные данные пользователя и управлять ими. Когда браузер перенаправляется к IdP, обмен данными имени пользователя и пароля происходит непосредственно между агентом клиента пользователя (браузером) и IdP. Необходимо создать отдельное соединение поставщика сервисов (SP) для каждого продукта PTC, находящегося в одном и том же объединении и использующего аутентификацию пользователя через один и тот же сервер авторизации (CAS).
Будут выполняться стандартные потоки аутентификации SAML и OIDC на основе конфигурации SSO. Для использования в конфигурации PTC SSO необходимо проверить поддерживаемые опции для конкретной технологии CAS перед ее выбором.
На следующей схеме последовательности показан поток аутентификации. В этом примере ThingWorx действует как поставщик сервисов (SP), а PingFederate - как CAS. ThingWorx использует протокол открытого стандарта SAML 2.0 для обмена аутентификацией между SP и IdP.
Процесс аутентификации имеет следующий вид.
1. Пользователь пытается получить доступ к поставщику сервисов.
2. Поставщик сервисов создает запрос SAML для пользователя и отправляет запрос в CAS.
3. CAS перенаправляет запрос SAML в IdP.
4. IdP перенаправляет пользователя на страницу аутентификации, чтобы он предоставил свои учетные данные (например, имя пользователя и пароль). После ввода пользователем своих учетных данных IdP генерирует ответ SAML. Если пользователь успешно прошел аутентификацию, ответ SAML будет включать утверждение SAML, которое содержит авторизацию пользователя.
5. Затем IdP перенаправляет ответ в CAS.
Для PingFederate PTC предоставляет сценарии автоматизации для конфигурации с PingFederate в качестве IdP. Дополнительные сведения см. в разделе Автоматическое конфигурирование PingFederate в качестве центрального сервера аутентификации.
Для сторонних IdP необходимо сконфигурировать CAS в настройке SSO.
Делегированная авторизация (OAuth)
Делегированная авторизация является концепцией, позволяющей поставщику сервисов (SP) выполнять действия или обращаться к ресурсам от сервера ресурсов (RS) от имени пользователя без открытия пользователем своих учетных данных для использования сервером ресурсов.
Из CAS запрашиваются лексемы доступа OAuth 2, которые затем используются в запросах данных от серверов ресурсов (RS). За проверку автора запроса в качестве аутентифицированного пользователя перед назначением лексем доступа в серверах ресурсов отвечает CAS. Для каждого из приложений PTC, участвующих в сценариях делегированной авторизации, должны быть созданы отдельные клиенты OAuth.
Продукты PTC в дальнейшем защищают ресурсы, защищенные с помощью OAuth, путем конфигурирования контекстных областей как дополнительных средств защиты. Когда поставщик сервисов отправляет лексему доступа вместе с запросом данных от сервера ресурсов, лексема доступа также должна иметь присоединенную контекстную область, зарегистрированную для данных в сервере ресурсов. Дополнительные сведения см. в разделе Управление контекстными областями в делегированной авторизации.
Продукты PTC поддерживают типы предоставления OAuth как для интерактивных, так и для неинтерактивных клиентов. Важно понимать функциональность клиента, чтобы определить подходящий тип предоставления прав для использования.
 |
Обязательно проверяйте документацию по конкретным продуктам PTC, чтобы подтвердить поддерживаемые для продукта типы предоставления OAuth.
|
◦ Интерактивный: пользователь проходит аутентификацию в клиенте, клиент будет запрашивать ресурсы от имени этого же пользователя; авторизация, разрешающая доступ к ресурсу, основывается на авторизации конечного пользователя.
◦ Не интерактивный: также известен как взаимодействие машина-машина (M2M). Клиент - это приложение, и он должен идентифицировать себя для CAS при запросе лексемы OAuth. Удостоверение в лексеме OAuth является удостоверением компьютера (клиент или участник сервиса) и не предназначено для пользователя.
На следующей схеме последовательности показан поток кода авторизации OAuth. ThingWorx - SP, PingFederate - CAS, Windchill - RS. ThingWorx в интерактивном клиенте конфигурируется для использования потока кода авторизации протокола авторизации открытого стандарта OAuth2, чтобы авторизовать поставщика сервисов для доступа к ресурсам безопасным, надежным и эффективным способом с использованием идентификатора конечного пользователя для авторизации загрузки ресурса.
Процесс авторизации выглядит следующим образом:
1. Когда получен ответ SAML от IdP, CAS отправляет страницу запроса на права авторизации пользователю для утверждения. CAS использует запрос на права авторизации для авторизации создания кода OAuth.
2. После того как пользователь предоставляет права доступа, CAS генерирует код авторизации OAuth. Затем CAS перенаправляет ответ SAML и код авторизации к поставщику сервисов.
3. После того как поставщик сервисов получит код авторизации OAuth, он запрашивает лексему доступа и обновляет лексему из CAS, используя код авторизации.
4. CAS проверяет код авторизации и создает лексему доступа OAuth и лексему обновления. Затем CAS отправляет обе лексемы поставщику сервисов.
5. Владелец ресурса (обычно пользователь) запрашивает содержимое от поставщика сервисов, которому требуются данные от сервера ресурсов.
6. Поставщик сервисов запрашивает содержимое от сервера ресурсов от имени владельца ресурса с использованием лексемы доступа.
7. Сервер ресурсов проверяет лексему доступа с помощью CAS.
8. Затем сервер ресурсов получает запрошенное содержимое и отправляет его поставщику сервисов.
9. После получения содержимого поставщик сервисов доставляет его владельцу ресурса.
Альтернативные технологии CAS могут быть сконфигурированы с помощью того же потока. Может потребоваться рассмотреть конкретные шаги и настройки конфигурации.
В неинтерактивном случае поток учетных данных клиента используется для передачи идентификатора и секрета клиента в CAS, чтобы загрузить лексему OAuth. Затем лексема OAuth передается серверу RS для загрузки запрошенного ресурса. Сервер RS должен быть настроен на поддержку типа предоставления учетных данных клиента, чтобы иметь возможность управлять лексемой OAuth и проверять запрос. На следующей схеме последовательности данных показан поток учетных данных клиента с неинтерактивным клиентом, запрашивающим ресурс из Windchill в качестве RS.
Можно также сконфигурировать архитектуру SSO как объединение с несколькими поставщиками сервисов и несколькими серверами ресурсов. Конфигурации SP и RS управляются одним CAS. Таким образом, все удостоверения пользователей совместно используются в объединении. В следующем примере Windchill Navigate - поставщик сервисов (SP), а Windchill и SAP - серверы ресурсов (RS).
