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

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

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

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

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

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

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

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

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

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

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

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


authentication federated-identity okta saml-2.0
person Stengel    schedule 05.02.2016    source источник
comment
У меня такая же проблема с возможностью аутентификации только для того, чтобы попасть на панель инструментов Okta. Удалось ли вам получить на это ответ? Ни поддержка Okta, ни документация не смогли объяснить, как это сделать. Это похоже на обычный вариант использования (входящий SAML аутентифицирован и перенаправляется на SP).   -  person Theo    schedule 21.04.2016

Ответы (2)


arrow_upward
1
arrow_downward

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

person Sam Yates    schedule 06.05.2016
comment
он там еще? - person pinkpanther; 02.04.2017

arrow_upward
0
arrow_downward

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

Okta поддерживает этот поток, используя входящий SAML, чтобы связать нижестоящий IDP с вашим потоком. Okta выполняет обнаружение пользователей в наборе правил, который вам необходимо настроить на Okta. На Okta IDP создайте SAML IDP Security -> Identity Providers и добавьте SAML IDP. Укажите URL-адрес входа в систему нижестоящего IDP. Затем добавьте правило маршрутизации для IDP Okta и отфильтруйте IP, устройство, приложение, атрибут каталога или группу, чтобы использовать созданный IDP в Okta. Затем в нисходящем IDP необходимо создать приложение SAML, которое будет возвращать утверждение в конечную точку SP. Okta не поддерживает глубокие ссылки SAML, поэтому вы должны передать RelayState в начальном запросе SAML, чтобы нисходящий IDP мог передать его обратно приложению, которое вызвало перенаправление HTTP 302, используя его значение.

person user12895119    schedule 13.02.2020