2016-06-03 2 views
0

Good Evening,SSO и существующие интеграции OAuth

Моя группа развертывает SSO - yay. У нас есть несколько приложений, которые непосредственно аутентифицируются с помощью Box.com, и все обновления токенов обрабатываются автоматически. После перехода на SSO мы не включили эти службы (приложения) в наш AD, поэтому у них нет доступа через шлюз SSO.

Мое (вероятно, неправильное) понимание того, как OAuth с поставщиком SSO в цикле работы:

Мы можем начать OAuth рукопожатия непосредственно с коробкой - но окно направит этот запрос провайдеру SSO. Затем поставщик SSO будет аутентифицировать учетные данные и передать «все хорошие» в поле, в котором будет выдан auth_token.

Это базируется на следующем из коробки:

«Если аутентификация приложения с помощью OAuth приставки 2.0, ваше приложения будет автоматически пусть вход на клиентах с их учетными данные компаниями, так же, как они относятся ко всем приложениям Box . Это относится также к популярным коммерческим услугам, таким как Okta, One Login и Ping. "

https://docs.box.com/docs/oauth-20

Так же как это фото: enter image description here

Таким образом, если учетные записи служб внешних приложений с коробкой не в AD ОССА (слишком много акронимов), они должны не сможете проверить подлинность?

Но эти приложения продолжают выполнять аутентификацию. Они могут обновить свой токен и продолжить доступ к нему, даже после перехода на SSO.

Где ошибка в моем понимании? Будут ли эти приложения добавлены в AD, или это произойдет из SSO, не повлияет на какие-либо из наших внешних зависимостей?

Спасибо!

ответ

0

Получил ответ от коробки:

сторонних приложений и интеграции использовать упорную аутентификации маркера модели. Это означает, что, если пользователь не намеренно регистрирует их приложения, или администратор инактивирует или удаляет свою учетную запись, этот пользователь никогда не будет повторно аутентифицирован после первоначального входа в систему. Вместо этого приложение/интеграция обновит свои жетоны. Обновление токенов не требует перехода через поток входа в систему единого входа, а генерация начального набора токенов .

Изменения состояния SSO, независимо от того, между SSO Off, Enabled и обязательно, или между двумя различными соединениями, не влияют на существующие сеансы аутентификации . Пользователи не будут принудительно выходить из системы, если включен SSO .

При следующей попытке входа в систему будет задействован новый поток SSO. В этом случае эти пользователи уже прошли аутентификацию в интеграцию до развертывания SSO. Изменение SSO повлияло бы на поведение в , что эти пользователи должны пройти аутентификацию через SSO в будущем; , однако из-за постоянной модели проверки подлинности, что «следующий логин» никогда не происходит, и эти пользователи могут продолжать обновлять токены и сохранять доступ, даже если не оспаривается проверка подлинности на IdP снова.