Конфигурирование центрального сервера аутентификации - PingFederate
PTC поддерживает использование PingFederate в качестве центрального сервера аутентификации (CAS). CAS управляет взаимоотношениями доверия между продуктами PTC, участвующими в инфраструктуре SSO. CAS выступает в роли посредника между приложениями, выполняя авторизацию входа пользователей после аутентификации пользователя, а затем выдавая и проверяя лексемы доступа, которыми обмениваются поставщики сервисов и серверы ресурсов.
Продукты PTC реализуют следующие элементы в среде SSO:
1. Для аутентификации пользователей с IdP используются утверждения SAML.
2. Затем, после того как пользователь прошел аутентификацию, PingFederate представляет пользователю страницу утверждения прав, на которой пользователя запрашивают, хочет ли он открыть общий доступ к своим данным из сервера ресурсов приложению, которое он использует.
При работе с PingFederate необходимо ознакомиться с документацией PingFederate (на английском языке). Ниже приведены некоторые общие советы, которые следует учитывать при развертывании PingFederate.
• Проверяйте максимальное время, в течение которого сессия входа пользователя в систему действительна, и решайте, должны ли эти значения использоваться в каждом из приложений, участвующих в решении SSO.
• Подтвердите, что системы работают в пределах приемлемого допуска расфазировки тактовых импульсов (на английском языке). Если один или несколько системных тактовых импульсов не синхронизированы с CAS и превышается заданное время допуска расфазировки тактовых импульсов в системе, то конфигурация будет вызывать ошибки и прекращать аутентификацию пользователей.
Федеративная аутентификация
Федеративная аутентификация - это процесс проверки запроса на вход пользователя в систему путем его сравнения с учетными данными, хранящимися в поставщике удостоверений.
В архитектуре SSO продукта PTC PingFederate не выполняет прямую аутентификацию входа пользователей. Вместо этого PingFederate необходимо сконфигурировать на перенаправление запросов на вход пользователя в IdP предприятия. IdP проверяет подлинность учетных данных пользователя и отправляет в PingFederate утверждение, что пользователь был аутентифицирован. Затем PingFederate отправляет запрашивающему приложению утверждение, что пользователь прошел аутентификацию, и авторизует вход пользователя. Во время этой транзакции PingFederate не обрабатывает учетные данные пользователя; когда браузер перенаправляется в IdP, обмен данными имени пользователя и пароля происходит непосредственно между агентом клиента пользователя (браузером) и IdP. Необходимо создать отдельное соединение поставщика сервисов для каждого продукта PTC, направляющего аутентификацию пользователя через PingFederate.
В следующем примере ThingWorx - поставщик сервисов, а PingFederate - CAS. ThingWorx использует протокол открытого стандарта SAML 2.0 для обмена данными аутентификации между поставщиком сервисов и поставщиком удостоверений.
Процесс аутентификации имеет следующий вид.
1. Пользователь пытается получить доступ к поставщику сервисов.
2. Поставщик сервисов создает запрос SAML для пользователя и отправляет запрос в CAS.
3. CAS перенаправляет запрос SAML в IdP.
4. IdP перенаправляет пользователя на страницу аутентификации, чтобы он предоставил свои учетные данные (например, имя пользователя и пароль). После ввода пользователем своих учетных данных IdP генерирует ответ SAML. Если пользователь успешно прошел аутентификацию, ответ SAML будет включать утверждение SAML, которое содержит авторизацию пользователя.
5. Затем IdP перенаправляет ответ в CAS.
PTC предоставляет сценарии автоматизации для конфигурации PingFederate с PingFederate в качестве IdP. Дополнительные сведения см. в разделе Автоматическое конфигурирование PingFederate в качестве центрального сервера аутентификации.
Для сторонних IdP необходимо сконфигурировать PingFederate в настройке SSO. Дополнительные сведения см. в разделе Конфигурирование аутентификации для сторонних IdP вручную.
Делегированная авторизация
Делегированная авторизация является концепцией, позволяющей поставщику сервисов выполнять действия или обращаться к ресурсам от сервера ресурсов (RS) от имени пользователя без открытия пользователем своих учетных данных для использования сервером ресурсов.
PingFederate создает лексемы доступа OAuth 2, которые продукты PTC включают в запросы данных от серверов ресурсов. За проверку подлинности лексем доступа в запросах к серверам ресурсов отвечает CAS. Для каждого из приложений PTC, участвующих в сценариях делегированной авторизации, должны быть созданы отдельные клиенты OAuth.
Продукты PTC в дальнейшем защищают ресурсы, защищенные с помощью OAuth, путем конфигурирования контекстных областей как дополнительных средств защиты. Когда поставщик сервисов отправляет лексему доступа вместе с запросом данных от сервера ресурсов, лексема доступа также должна иметь присоединенную контекстную область, зарегистрированную для данных в сервере ресурсов. Дополнительные сведения см. в разделе Управление контекстными областями в делегированной авторизации.
В следующем примере ThingWorx - поставщик сервисов, PingFederate - CAS, а Windchill - сервер ресурсов. 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. После получения содержимого поставщик сервисов доставляет его владельцу ресурса.
Можно также реализовать архитектуру SSO с несколькими серверами ресурсов. В данном примере ThingWorx Navigate - поставщик сервисов, а Windchill и SAP - серверы ресурсов.
