#authentication #weblogic #saml
#аутентификация #weblogic #saml
Вопрос:
Мы разрабатываем приложение для самостоятельной регистрации.
Наше приложение позволяет пользователям регистрироваться в веб-приложениях и развертывается на сервере приложений weblogic 10.3.5. Weblogic подключен к локальной системе ldap. Как только пользователь регистрируется в нашем приложении, мы вызываем корпоративные сервисы для генерации идентификатора пользователя. активация пароля, аутентификация обрабатывается корпоративными сервисами. который также имеет корпоративный ldap, который содержит всех пользователей в компании.
Этот подход отлично работает для «новых пользователей», т.Е. Пользователей, которых нет в корпоративном ldap или локальном ldap: пользователи вводят свои данные и получают идентификатор пользователя, который мы затем копируем в локальный ldap, как только пользователь активирует свою учетную запись.
Вариант использования, с которым мы сталкиваемся в данный момент, заключается в том, как обращаться с «существующими» пользователями, которые хотят зарегистрироваться. Это пользователи, которые в настоящее время находятся в корпоративном ldap и хотят «зарегистрироваться» в наших приложениях. Они отклоняются во время обычного процесса регистрации, поскольку они уже существуют в совместном ldap.
Что я хотел бы сделать, так это заставить их войти в систему (просто чтобы они не регистрировались от имени кого-то другого), и как только они войдут в систему, просто скопируйте их данные в локальный ldap.
Проблема в том, что, даже если они успешно аутентифицированы корпоративной службой, они (пока не существуют) для сервера weblogic. есть ли способ получить идентификатор пользователя, который поставляется с токеном аутентификации?
Метод аутентификации — SAML 1.1 Приложение представляет собой стандартное веб-приложение на основе Java EE servlet, использующее платформу struts2.
Любые идеи будут высоко оценены.
Ответ №1:
В WebLogic вы можете определить несколько поставщиков аутентификации и настроить их в том порядке, в котором вы хотите, чтобы система использовала. Поскольку вы копируете данные, вам придется программно проверять наличие учетной записи, прежде чем пытаться создать ее на сервере LDAP.
Было бы намного проще, если бы вы использовали внешний сервер LDAP напрямую вместо копирования данных на внутренний сервер LDAP, что позволило бы вам попытаться войти в систему пользователя и создать учетную запись только при улавливании соответствующего исключения.