Настроить Okta для обработки аутентификации SAML от имени нашего веб-приложения, отличного от Saml?

Наша компания поддерживает веб-приложение, состоящее из внешнего интерфейса и внутреннего интерфейса (Node.js), и мы поддерживаем стандартную аутентификацию по имени пользователя и паролю. Несколько наших партнеров обратились с просьбой о поддержке системы единого входа на базе SAML, чтобы их конечные пользователи могли получить доступ к нашему веб-приложению по ссылке на своих порталах без необходимости повторного входа в систему.

Вопрос: Нужно ли нам превращать наше приложение в полноценного поставщика услуг (SP), внедряя sdk / библиотеку SAML в наш интерфейс и серверную часть?

Или можно использовать стороннего поставщика аутентификации, такого как Okta, для обработки мелочей SAML за кулисами, а затем перенаправить конечного пользователя в наше приложение, возможно, с токеном (JWT?), Чтобы мы могли получить информацию о пользователе из Okta ?

Я прочитал все, что смог найти на сайте Okta и здесь, и не смог найти окончательного ответа, либо да, это возможно (с примером), либо нет, вы не можете этого сделать.


saml single-sign-on okta
person Eric Paquette    schedule 18.05.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Как вы уже упоминали в своем вопросе, есть 2 возможных способа сделать это.

  1. Обновите свое приложение, чтобы поддерживать процесс входа в SAML с вашим приложением как SP, и в этом случае вам не нужно будет использовать стороннего поставщика аутентификации.

  2. Если вы не хотите вдаваться в подробности SAML, вы можете использовать стороннего поставщика, такого как Okta, в качестве посредника, который будет использовать ответы SAML от IdP (используемый вашими внешними клиентами), а затем преобразовать это утверждение в Токен открытого идентификатора (JWT). В этом случае Okta будет действовать как IdP (сервер авторизации) для вашего веб-приложения и генерировать токены идентификатора. Затем ваше приложение должно будет реализовать поток входа в систему Open ID connect. Вы можете обратиться к http://developer.okta.com/code/javascript/okta_sign-in_widget_ref для этого.

person Vijet M    schedule 19.05.2017
comment
Спасибо, можно ли автоматизировать этот поток, чтобы на уровне Okta не было взаимодействия с пользователем, например нажатия на приложение? В идеале конечный пользователь нажимает кнопку на портале своей компании и в конечном итоге без проблем входит в приложение нашей компании. - person Eric Paquette; 21.05.2017
comment
Что ж, не может быть ситуации, когда нет взаимодействия с пользователем, поскольку пользователь должен будет щелкнуть ссылку / кнопку приложения, как вы сказали, но пользователь также должен уже аутентифицировать себя с помощью своего собственного поставщика удостоверений. Если он еще не прошел аутентификацию, мы не сможем сгенерировать ответ SAML в вашем случае, поскольку IdP должен знать некоторую информацию о пользователе, чтобы сгенерировать ответ. - person Vijet M; 21.05.2017
comment
В вашем случае предположим, что внешние клиенты имеют свои собственные учетные данные Active Directory в сети своей компании для входа в систему. Когда пользователь пытается войти в ваше веб-приложение, Okta перехватит этот запрос и отправит запрос аутентификации SAML IdP (Active Directory). Если пользователь еще не вошел в систему, AD попросит пользователя войти в систему, чтобы сгенерировать ответ SAML. Если пользователь уже вошел в свою учетную запись AD, работа будет гладкой, в том смысле, что пользователю не нужно будет снова входить в систему, чтобы получить доступ к вашему приложению. Надеюсь, это имеет смысл. - person Vijet M; 21.05.2017
comment
Думаю, я неправильно понял ваш вопрос. Вы хотели спросить, нужно ли пользователю нажимать на приложение на уровне Okta. Я считаю, что это возможно, т. Е. Вам не понадобится второе перенаправление. Я не совсем уверен в этом. Я спрошу и дам вам знать. Полное раскрытие: я работаю в Okta. - person Vijet M; 21.05.2017
comment
Спасибо Vijet, позвольте мне прояснить свой вопрос. Вот идеальный сценарий: конечный пользователь входит во внутреннюю сеть AD своей компании, открывает свой портал, затем нажимает кнопку, чтобы запустить наше веб-приложение. Аутентификация SAML обрабатывается между Okta и IdP конечного пользователя, и после аутентификации пользователя Okta запускает наше веб-приложение, передавая информацию о пользователе, используя какой-либо безопасный метод, который уже поддерживается нашим веб-приложением (например, Open Connect ID или простой SWA). Теоретически конечный пользователь даже сейчас не стал бы Okta посредником в аутентификации между их порталом и нашим веб-приложением. - person Eric Paquette; 22.05.2017