Выполнение аутентификации пользователя в Java EE / JSF с использованием j_security_check

156

Мне интересно, каков нынешний подход в отношении аутентификации пользователей для веб-приложения, использующего JSF 2.0 (и, если какие-либо компоненты существуют), и основные механизмы Java EE 6 (вход / проверка разрешений / выходов) с информацией о пользователях, хранящейся в JPA организация. Учебник по Oracle Java EE немного разбирается в этом (работают только с сервлетами).

Это не использует совершенно другую платформу, такую ​​как Spring-Security (acegi) или Seam, но старается придерживаться новой платформы Java EE 6 (веб-профиль), если это возможно.

ngeek
источник

Ответы:

85

После поиска в Интернете и попыток различных способов, вот что я бы предложил для аутентификации Java EE 6:

Настройте область безопасности:

В моем случае, у меня были пользователи в базе данных. Поэтому я последовал за этой записью в блоге, чтобы создать JDBC Realm, который мог бы аутентифицировать пользователей на основе имени пользователя и паролей, хэшированных в MD5, в моей таблице базы данных:

http://blog.gamatam.com/2009/11/jdbc-realm-setup-with-glassfish-v3.html

Примечание: пост рассказывает о пользователе и групповой таблице в базе данных. У меня был класс User с атрибутом перечисления UserType, сопоставленный посредством аннотаций javax.persistence в базу данных. Я настроил область с той же таблицей для пользователей и групп, используя столбец userType в качестве столбца группы, и он работал нормально.

Использовать аутентификацию формы:

Следуя приведенному выше сообщению в блоге, настройте свои web.xml и sun-web.xml, но вместо использования BASIC-аутентификации используйте FORM (на самом деле, не имеет значения, какой вы используете, но в итоге я использовал FORM). Используйте стандартный HTML, а не JSF.

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

 @Resource
 private SessionContext sessionContext;

С принципалом я могу проверить имя пользователя и, используя EJB Entity Manager, получить информацию о пользователе из базы данных и сохранить ее в моем SessionInformationEJB.

Выйти:

Я также искал лучший способ выхода из системы. Лучший из найденных мной - это использование сервлета:

 @WebServlet(name = "LogoutServlet", urlPatterns = {"/logout"})
 public class LogoutServlet extends HttpServlet {
  @Override
  protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
   HttpSession session = request.getSession(false);

   // Destroys the session for this user.
   if (session != null)
        session.invalidate();

   // Redirects back to the initial page.
   response.sendRedirect(request.getContextPath());
  }
 }

Хотя мой ответ действительно опаздывает с учетом даты вопроса, я надеюсь, что это поможет другим людям, которые попадают сюда из Google, так же, как и я.

Чао,

Вит Суза

Виктор Э. Сильва Соуза
источник
15
Небольшой совет: вы используете request.getSession (false) и вызываете invalidate () для этого. request.getSession (false) может вернуть ноль, если сеанса нет. Лучше сначала
проверь, не пусто
@Vitor: Привет ... Хотели бы вы сказать что-нибудь о том, когда стоит перейти от безопасности на основе контейнеров к альтернативам, таким как Сиро или другие? Смотрите более сфокусированный вопрос здесь: stackoverflow.com/questions/7782720/…
Раджат Гупта
Похоже, что GlassD JDBC Realm не поддерживает хранение хэшей с солеными паролями. Это действительно лучшая практика, чтобы использовать его в этом случае?
Лии
Извините, не могу вам помочь. Я не эксперт по Glassfish. Может быть, задать этот вопрос в новой теме, чтобы увидеть, что люди говорят?
Виктор Э. Сильва Соуза
1
Lii, вы можете работать с соленой, используя контейнер из стеклянной рыбы. Настройте свой хэлм, чтобы не использовать хэш. Он будет сравнивать простое значение, которое вы вставляете для пароля HttpServletResponse#login(user, password), таким образом, вы можете просто получить из БД соль пользователя, итерации и все, что вы используете для посола, хешировать пароль, введенный пользователем с помощью этой соли, а затем попросить контейнер аутентифицироваться с помощью HttpServletResponse#login(user, password),
emportella
152

Я полагаю, вы хотите аутентификацию на основе форм с использованием дескрипторов развертывания и j_security_check.

Вы также можете сделать это в JSF, просто используя те же predefinied имена полей j_usernameи , j_passwordкак показано в руководстве.

Например

<form action="j_security_check" method="post">
    <h:outputLabel for="j_username" value="Username" />
    <h:inputText id="j_username" />
    <br />
    <h:outputLabel for="j_password" value="Password" />
    <h:inputSecret id="j_password" />
    <br />
    <h:commandButton value="Login" />
</form>

Вы можете выполнить ленивую загрузку в Userполучателе, чтобы проверить, Userвошел ли уже в систему, и если нет, то проверить Principal, присутствует ли в запросе, и если да, то получить Userсвязанный с j_username.

package com.stackoverflow.q2206911;

import java.io.IOException;
import java.security.Principal;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.context.FacesContext;

@ManagedBean
@SessionScoped
public class Auth {

    private User user; // The JPA entity.

    @EJB
    private UserService userService;

    public User getUser() {
        if (user == null) {
            Principal principal = FacesContext.getCurrentInstance().getExternalContext().getUserPrincipal();
            if (principal != null) {
                user = userService.find(principal.getName()); // Find User by j_username.
            }
        }
        return user;
    }

}

User, Очевидно , доступен в JSF EL на #{auth.user}.

Для выхода сделайте HttpServletRequest#logout()(и установите Userв ноль!). Вы можете получить ручку HttpServletRequestв JSF ExternalContext#getRequest(). Вы также можете просто полностью аннулировать сеанс.

public String logout() {
    FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
    return "login?faces-redirect=true";
}

Для остатка (определение пользователей, ролей и ограничений в дескрипторе и области развертывания) просто следуйте учебному руководству по Java EE 6 и документации по сервлет-контейнеру обычным способом.


Обновление : вы также можете использовать новый Servlet 3.0 HttpServletRequest#login()для программного входа в систему вместо использования, j_security_checkкоторое само по себе может быть недоступно для диспетчера в некоторых контейнерах сервлетов. В этом случае вы можете использовать fullworthy формы JSF и боб с usernameи passwordсвойствами и loginспособом , которые выглядят следующим образом :

<h:form>
    <h:outputLabel for="username" value="Username" />
    <h:inputText id="username" value="#{auth.username}" required="true" />
    <h:message for="username" />
    <br />
    <h:outputLabel for="password" value="Password" />
    <h:inputSecret id="password" value="#{auth.password}" required="true" />
    <h:message for="password" />
    <br />
    <h:commandButton value="Login" action="#{auth.login}" />
    <h:messages globalOnly="true" />
</h:form>

И это представление управляет управляемым бином, который также запоминает первоначально запрошенную страницу:

@ManagedBean
@ViewScoped
public class Auth {

    private String username;
    private String password;
    private String originalURL;

    @PostConstruct
    public void init() {
        ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
        originalURL = (String) externalContext.getRequestMap().get(RequestDispatcher.FORWARD_REQUEST_URI);

        if (originalURL == null) {
            originalURL = externalContext.getRequestContextPath() + "/home.xhtml";
        } else {
            String originalQuery = (String) externalContext.getRequestMap().get(RequestDispatcher.FORWARD_QUERY_STRING);

            if (originalQuery != null) {
                originalURL += "?" + originalQuery;
            }
        }
    }

    @EJB
    private UserService userService;

    public void login() throws IOException {
        FacesContext context = FacesContext.getCurrentInstance();
        ExternalContext externalContext = context.getExternalContext();
        HttpServletRequest request = (HttpServletRequest) externalContext.getRequest();

        try {
            request.login(username, password);
            User user = userService.find(username, password);
            externalContext.getSessionMap().put("user", user);
            externalContext.redirect(originalURL);
        } catch (ServletException e) {
            // Handle unknown username/password in request.login().
            context.addMessage(null, new FacesMessage("Unknown login"));
        }
    }

    public void logout() throws IOException {
        ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
        externalContext.invalidateSession();
        externalContext.redirect(externalContext.getRequestContextPath() + "/login.xhtml");
    }

    // Getters/setters for username and password.
}

Этот способ Userдоступен в JSF EL #{user}.

BalusC
источник
1
Я обновил вопрос, включив в него отказ от ответственности, который j_security_checkможет не работать для всех контейнеров сервлетов.
BalusC
1
Ссылка из Учебного руководства по Java по использованию программной безопасности с веб-приложениями: java.sun.com/javaee/6/docs/tutorial/doc/gjiie.html (с использованием сервлетов): В классе сервлетов вы можете использовать: @WebServlet(name="testServlet", urlPatterns={"/ testServlet "}) @ServletSecurity(@HttpConstraint(rolesAllowed = {"testUser", "admin”})) И для каждого метода уровень: @ServletSecurity(httpMethodConstraints={ @HttpMethodConstraint("GET"), @HttpMethodConstraint(value="POST", rolesAllowed={"testUser"})})
ngeek
3
И твоя точка зрения ..? Применимо ли это в JSF? Ну, в JSF есть только один сервлет, FacesServletи вы не можете (и не хотите) изменять его.
BalusC
1
@BalusC - Когда вы говорите, что вышесказанное - лучший способ, вы подразумеваете использование j_security_check или программного входа?
simgineer
3
@simgineer: запрошенный URL-адрес доступен в виде атрибута запроса с именем, определенным пользователем RequestDispatcher.FORWARD_REQUEST_URI. Атрибуты запроса в JSF доступны ExternalContext#getRequestMap().
BalusC
7

Следует отметить, что это возможность полностью оставить проблемы аутентификации переднему контроллеру, например, веб-серверу Apache, и вместо этого оценить HttpServletRequest.getRemoteUser (), который является представлением JAVA для переменной среды REMOTE_USER. Это позволяет также сложные проекты входа в систему, такие как аутентификация Shibboleth. Фильтрация запросов к сервлет-контейнеру через веб-сервер - хороший дизайн для производственных сред, часто для этого используется mod_jk.

Матиас Ронге
источник
4

Проблема HttpServletRequest.login не устанавливает состояние аутентификации в сеансе была исправлена ​​в 3.0.1. Обновите Glassfish до последней версии, и все готово.

Обновление довольно просто:

glassfishv3/bin/pkg set-authority -P dev.glassfish.org
glassfishv3/bin/pkg image-update
Ханс Бачер
источник
4
ссылка не работает на какую проблему вы ссылались?
simgineer