2015-10-13 4 views
1

Мы реализуем решение для единого входа в систему с использованием PingFederate с сторонним продуктом, который включает SAML2 из коробки.Продолжить сеанс PingFederate IDP с SP

Однако мы пытаемся решить вопрос о том, как остановить тайм-аут сеанса IDP, если пользователь все еще активно использует SP.

Сторонний продукт поддерживает запрос пустого ресурса на стороне IDP с намерением, чтобы этот URL-адрес привел к расширению сеанса IDP.

Я ничего не вижу в PingFederate, который поддерживает что-либо подобное. Кто-нибудь знает, как это вообще разрешено? Есть ли способ продлить сеанс PingFederate, например. Вызов API, HTTP POST до конечной точки, что?

Или SP нуждается в конструировании нового запроса на аутентификацию? Если да, то это приводит к тому, что новый ответ/токен SAML выдается с новой датой NotOnOrAfter?

+0

Зачем вам нужно поддерживать сеанс IdP? Сеанс SP должен быть полностью автономным. –

+0

Мы делаем это, чтобы включить единый вход. Вы переходите к одному приложению, получаете запрос на вход в систему, какое-то время используете это приложение, а затем переходите к другому приложению, в которое вы легко входите. Если вы не поддерживаете сеанс IDP, даже если вы активно использовали первый SP, вам будет предложено снова войти в систему при переходе на второй SP, если срок действия IDP истек. – ChrisC

+0

Просто используйте асинхронный аутентификационный адаптер, например IWA, если это то, что вам нужно ... То, что вы пытаетесь сделать здесь, не поддерживается SAML ... Это поддерживается традиционным WAM, например, как отметил Ян, PingAccess , Я полагаю, вы могли бы использовать OAuth или OIDC. –

ответ

1

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

Обычно клиенты обрабатывают это, делая сеанс в IDP долговечным, так что пользователю не предлагается снова войти в систему при переключении между SP.

Если вы контролируете IDP и SP, я бы рекомендовал использовать PingAccess совместно с PingFederate. Вы все еще можете подключиться к приложению через PingFed, но PingAccess позволит вам управлять сеансами между приложениями.

+0

Спасибо @Ian. Я решил сделать сеанс IDP долговечным, но затем он требует явного выхода из системы, чтобы остановить доступ пользователей, потому что всякий раз, когда SP истекает время, в следующий раз, когда пользователь обратится к сайту, SP отскакивает пользователя от IDP, PingFederate скажет: все хорошо, вы можете войти », и они вернулись без аутентификации. Другими словами, сеанс IDP будет отменять все остальное с точки зрения безопасности. (Если я не понял, как это работает?) – ChrisC

+0

Да, мы контролируем IDP и SP (SP только в том смысле, что мы развертываем стороннее приложение), поэтому у нас есть PingAccess, но мне сказал наш поставщик реализации, что если мы используем веб-интерфейс браузер SSO, тогда PingAccess не играет никакой реальной роли. Первоначально я думал, что мы могли бы использовать OpenID Connect между клиентом и PA, а затем любые стандартные (SAML, OAuth, OpenToken, что угодно) между PF и back-end системами, но мне сказали, что это не так, как это работает. Можете ли вы рассказать о том, как мы используем PA в качестве менеджера шлюзов/сеансов, но все еще используем SAML для объединения в задние системы? – ChrisC

+0

Зачем использовать SAML для бэкэндов? Просто используйте SAML для PF как SP от других партнеров, а затем выполните внешние интерфейсы ваших бэкэнд-приложений с помощью PingAccess. SAML не требуется для поддержки приложений. Выбросьте атрибуты в заголовках, чтобы приложения потребляли, и все готово.В ноябре состоится 4-дневное обучение PingAccess, возможно, будет полезно посетить вас! https://4.pingidentity.com/15-11-10-BurlingtonPingAccessRegistration.html –

Смежные вопросы