Настройка Okta для посредничества между нашим заявлением SP и IdP

Question

Мы являемся поставщиком услуг, у которого есть приложение SAML, позволяющее IdPs аутентифицировать пользователей для нас. Для того, чтобы убедиться, что все на той же странице

• идентификации (IDP) является приложением, чья работа заключается в том, чтобы проверить подлинность пользователей
• Service Provider (SP) является конечным приложением, которое федератов идентичности и аутентификации в IdP
• SAML - это протокол, позволяющий IdPs делать достоверные утверждения идентичности для SP. Мы используем SAML 2.0 (http://en.wikipedia.org/wiki/SAML_2.0)

Более подробная информация о федеративной идентификации здесь: http://developer.okta.com/docs/guides/saml_guidance.html

Мы в настоящее время только с помощью окта как IdP, но столкнулись с ситуацией, когда нам нужно интегрировать с отдельным IdP. Мы хотели бы, чтобы наше приложение связывалось только с Okta, и у Okta есть дело с разговором с этим отдельным IdP и подтверждением их утверждений. Из-за нашего конкретного варианта использования наше приложение знает, какой базовый IdP следует использовать, поэтому нет необходимости в IdP Discovery.

Мы хотели бы настроить окт так, чтобы поток аутентификации следующим образом:

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

2. Okta и базовый IdP делает все необходимое для аутентификации пользователя и проверки подлинности

3. Наше приложение получает один ответ (через HTTP-POST) нашей конечной точке ACS, аутентифицирующей пользователя, подписывается окт

С точкой зрения конечного пользователя, они перейти к service-provider.com, перенаправляются через окт в underlying-idp.com, выполнить необходимую проверку подлинности, а затем перенаправляется обратно в сервис-провайдер .com. Конечный пользователь не знает о среднем слое Okta, за исключением, возможно, URL-адреса Okta, который кратковременно появляется в адресной строке браузера во время перенаправления.

До сих пор мы смогли настроить входящий SAML в нашем экземпляре Okta, чтобы пользователи могли пройти аутентификацию в Okta через базовый IdP. Мы перенаправляем наше приложение на конечную точку, указанную на странице конфигурации входящего SAML, с помощью SAMLRequest, но это приводит пользователей к панели мониторинга Okta, поскольку ссылка предназначена только для аутентификации пользователей в Okta, а не для аутентификации пользователей для SP с использованием Okta. Смотрите нашу соответствующую конфигурацию:

• Configuration for our app in Okta which allows us to use Okta as a direct IdP
• Configuration results of the Inbound SAML. We redirect our SAMLRequest to the Assertion Consumer Service URL given

Как мы можем настроить окт так, что наше использование возможен случай? В идеале мы хотели бы, чтобы Окта служил посредником или посредником, проверяя и передавая запросы/утверждения SAML. В частности, нам не нужны эти пользователи для аутентификации пользователей Okta; мы просто нуждаемся в Okta, чтобы утверждать, что пользователь - это тот, кто, по их словам, основан на основополагающем утверждении IdP.

Answer 1

Kinda звучит так, как будто вам нужна функция IdP Discovery, которую Okta имеет в дорожной карте в конце этого года в сочетании со своей входящей настройкой SAML с отношениями с другим IdP. Я считаю, что это возможно, чтобы реализовать это с помощью специальной страницы входа. Они упоминали об этом с профессиональными услугами, но лично я бы чувствовал себя намного лучше, когда они построили обнаружение IdP в платформе.