Угловое приложение для аутентификации SSO с вызовом сервисного шлюза

У нас есть приложение, созданное с использованием Angular. И приложение запускает бэкэнд REST api для отображения данных.

Проблема заключалась в том,

Приложение использует аутентификацию LDAP SSO для проверки пользователя (это внутреннее приложение внутри компании, поэтому сторонних пользователей нет)

Шаги:

  1. Если пользователь запускает сайт, он перенаправляется на вход в систему WebSec, где пользователь предоставляет имя пользователя и пароль для аутентификации (неявный поток).

  2. После успешной аутентификации мы получим токен доступа JWT из WebSec, который будет храниться в хранилище сеанса и будет использоваться в качестве токена-носителя для внутренних служб.

  3. У серверной службы есть свой сертификат WebSec для проверки этого токена JWT на своей стороне, если он не ответит с ошибкой аутентификации.

Для Front end - мы используем Angular. Для back end - мы Java, Sprint boot.

Вопросы,

  1. Это правильный способ аутентификации пользователя?
  2. Если да, то насколько безопасен неявный поток. Ссылка: https://www.instagram.com/developer/authentication/. Все рекомендуя Явный поток (вызов на стороне сервера). Наше приложение пользовательского интерфейса поддерживается на другом сервере, а серверные службы обслуживаются на другом сервере.

Буду признателен, если кто-нибудь предоставит решение по этому поводу.


spring-boot angular websecurity single-sign-on ldap
person Raja    schedule 19.07.2019    source источник
comment
Поддерживает ли ваша система единого входа LDAP явный поток?   -  person wolverine    schedule 24.07.2019
comment
Можете ли вы внести какие-либо изменения в систему единого входа LDAP?   -  person wolverine    schedule 24.07.2019

Ответы (2)


arrow_upward
1
arrow_downward

Лучший способ, который я видел до сих пор, заключается в следующем (я также использую сервер единого входа MS, как вы описали), но я бы рекомендовал делать это так, как это делает Discord:

  1. Ваш веб-интерфейс перенаправляет на систему единого входа с redirect_link и application_id и утверждает, что запрашивает
  2. Ваша система единого входа перенаправляется на redirect_link, если аутентификация прошла успешно и application_id известен, но со случайным созданием code=$myCode, это может быть JWT или любая другая длинная строка.
  3. Ваш внешний интерфейс отправляет этот код на ваш сервер, а затем он запрашивает у сервера SSO действительный code и запрашивает реальный токен носителя аутентификации.
  4. Если все в порядке, ваш Frontend получает настоящий токен аутентификации от вашего API

Если вся эта цепочка успешна, вы можете быть уверены, что с вашей внутренней сетью все в порядке. Это для внутренней компании достаточно хороший подход.

Для внешнего использования вы можете предоставить безопасный ключ с шагами 1 и 2, который sso должен предоставить обратно для внешнего интерфейса, который создается из внешнего интерфейса, чтобы быть уверенным, что это перенаправление исходит из вашего SSO.

РЕДАКТИРОВАТЬ: подробнее о шифровании:

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

person JohnnyDevNull    schedule 24.07.2019

arrow_upward
3
arrow_downward

Проблема с неявным потоком заключается в том, что токен JWT присутствует в URL-адресе. Неявный поток может быть реализован в вашем Front-end или Back-end, оба не рекомендуются, но выполнение этого во Front-end имеет больше уязвимостей, что вы и пытаетесь сделать, если я правильно понял ваш вопрос.

Я бы реализовал это следующим образом.

  1. Ваш интерфейс будет перенаправлен на вход в систему WebSec
  2. При успешном входе в систему WebSec перенаправит на вашу серверную часть
  3. Серверная часть извлекает токен JWT
  4. Серверная часть создает одноразовый токен и перенаправляет на ваш интерфейс с помощью этого одноразового токена.
  5. Front-end извлекает одноразовый токен и POST токен в Back-end, чтобы получить JWT-токен.
person wolverine    schedule 19.07.2019
comment
Это довольно плохой способ позволить API перенаправить на интерфейс. Я бы никогда не рекомендовал такой подход. - person JohnnyDevNull; 24.07.2019
comment
@JohnnyDevNull хотел бы знать, что плохого в этом подходе и как лучше это сделать, не могли бы вы пролить свет? - person wolverine; 24.07.2019
comment
Я не рекомендую неявный поток, четко упомянутый в моем ответе, но если вы видите пункт № 2 в вопросе, кажется, что его SSO не поддерживает явный поток. Итак, я ответил, насколько лучше он может это реализовать, если его система единого входа не поддерживает явный поток. Если его SSO поддерживает явный поток, я определенно рекомендую только это, и сам пользователь, кажется, знает это на основе ссылки, которой он поделился. - person wolverine; 24.07.2019
comment
Что ж, правда, но только для внутреннего использования неявный поток также должен быть достаточно хорош. Когда кто-то пытается взломать изнутри, возникают другие проблемы с безопасностью. - person JohnnyDevNull; 24.07.2019