#java #spring #azure #security #login
#java #spring #azure #Безопасность #аутентификация
Вопрос:
У меня есть проект Java Spring Security, который связан с Azure AD через зарегистрированное приложение. Таким образом, я могу перенаправлять пользователей в Microsoft для входа в систему с их учетной записью Azure, прежде чем они смогут просматривать определенные страницы или использовать определенные конечные точки. Все это отлично работает.
Проблема в том, что у меня есть другое AD (и, возможно, больше в будущем), в которое я также хочу, чтобы пользователи могли входить в систему. Однако, насколько я вижу, Spring Security позволяет настраивать только 1 объявление, поэтому, когда пользователь хочет войти в систему, он всегда должен быть частью текущего связанного объявления.
Я пытался искать различные решения для этого, например, синхронизировать всех пользователей из внешнего AD с активным AD. Для этого я смог получить список пользователей, но когда я захотел добавить их в AD, единственными конечными точками API, которые я смог найти, были создание новых учетных записей вместо ссылки на них из внешнего AD. Другой идеей было настроить Spring Security для простой аутентификации в более чем 1 AD. Но, насколько я видел, это невозможно.
В конце концов, я просто хочу, чтобы пользователи из обоих AD могли входить в мое приложение, используя свои существующие учетные данные, без необходимости приглашать каждого вручную. Какова наилучшая практика при работе с подобной ситуацией? Я был бы очень признателен за помощь, указывающую мне правильное направление. Заранее спасибо!
Комментарии:
1. Вы могли бы подумать о том, чтобы сделать приложение многопользовательским.. читайте об этом здесь.. learn.microsoft.com/en-us/azure/active-directory/develop /…
2. Помните, что многопользовательские приложения означают, что любой клиент может войти в систему. Вы должны проверить на своем серверном сервере, какой клиент использовался для входа, и заблокировать их, если они использовали тот, который вам не нужен. Если вы, конечно, не хотите, чтобы любой клиент мог войти в систему 🙂
3. Да, это хороший момент от @juunas, как обычно.. Создание многопользовательского приложения может избавить вас от необходимости вручную приглашать всех и каждого , но вам нужно будет приложить некоторые усилия для правильной реализации этого, например, использовать / common endpoint, проверять клиента, понимать структуру согласия и необходимые разрешения и так далее .. так что прочитайте и посмотрите, имеет ли это смысл.. удачи!
4. Это звучит очень многообещающе! Я собираюсь изучить страницу, на которую вы ссылались, и многопользовательские приложения в целом. Необходимость прилагать дополнительные усилия к серверной части не должна быть проблемой, если это позволяет достичь моей цели. Спасибо!