Взаимодействие моего приложения с существующими системами аутентификации

Question

Я пишу веб-приложение, которое будет иметь собственный механизм авторизации / аутентификации (традиционный cookie / пользователь на основе сеанса / проход). Однако, в зависимости от организации, которая лицензирует программное обеспечение, я хочу, чтобы они могли подключить свою собственную существующую систему внутренней аутентификации, чтобы заменить мою. В идеале, они должны были бы выполнить как можно меньше кода на своем конце; Я пытаюсь сделать это главным образом размещенным сервисом. Я знаю о существовании OAuth, но не совсем понимаю, как бы я реализовал систему на более высоком уровне. Любые советы будут оценены.

Answer 1

Для какой платформы вы разрабатываете? PHP, Java, .NET или другое?

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

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

См. Ссылки из другого моего поста для ссылок на документацию протокола. Службы Google также имеют хорошую диаграмму единого входа с SAML в действии.

Answer 2

Ваш вопрос запутывает те самые вещи (authn / authz, то есть политику и приложение), которые вы хотите распутать. Ответ, который вы ищете, требует разделения этих проблем.

«Стандартный» ответ состоит в том, чтобы отделить политику authn / authz, обычно используя PEP (точку применения политики) для обеспечения выполнения решений, принятых PDP (точка принятия решения). SAML предоставляет стандарты для связи между ними.

Вы закрываете свое приложение (и, как правило, многие другие), защищенное PEP. Это может быть встроено в приложение (например, как перехватчик Tomcat), но лучше, если оно работает в отдельном контейнере в качестве прокси. Единственное, что доступно снаружи - это ПКП. Это проверяет каждый запрос, гарантирует, что пользователь прошел проверку подлинности, и (для единого входа) гарантирует, что каждый запрос содержит маркер безопасности.

Если нет, PEP перенаправляет запрос в PDP для аутентификации (экран входа в систему). PDP присоединяет маркер безопасности и перенаправляет запрос обратно в PEP. Поскольку в запросе теперь есть действительный токен, PEP перенаправляет его в приложение за брандмауэром.