Как реализовать Security в Java EE? Часть 2

В данном уроке мы рассмотрим как реализовать безопасность в приложениях используя БД.

Введение

В прошлом уроке, Как реализовать Security в Java EE? Часть 1, мы рассматривали простой способ настройки безопасности для приложения. Он будет отталкиваться от предыдущего и строиться на нем. В сегодняшнем уроке мы сделаем настройку безопасности используя БД. Также, нам понадобиться настроенный datasource. Это не тяжело сделать и настраивается очень быстро.

 

Шаг 1. Создание и привязка к datasource

Теперь нам нужно создать источник данных для нашего приложения и сервера. Раньше, просто работая с JPA мы хранили эту информацию внутри приложения, сейчас нам нужно вынести все это на сервер. Чтобы не создавать большой урок, детально об этом написано здесь WildFly настройка и использование DataSource в JPA. В данном уроке, настройте только источник, создавать сущности и persistence не обязательно.

 

 

Шаг 2. Настройка домена

После настройки источника, нужно настроить домен, для нашего приложения. Опять же, в прошлом мы использовали домен other. Здесь создадим свой конкретно для приложения и базы.

Внимание! Перед этими изменениями остановите сервер. Иначе он может перетереть ваши настройки.

Открываем файлик в WildFly который находиться по пути: standalone/configuration/standalone.xml Там ищем тег security-domains  и внутрь него добавляем свой доммен.

<security-domain name="securityexampledomain" cache-type="default">
    <authentication>
        <login-module code="Database" flag="required">
            <module-option name="dsJndiName" value="java:jboss/datasources/DataSourceEx"/>
            <module-option name="principalsQuery" value="SELECT password FROM accounts WHERE login=?"/>
            <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM accounts WHERE login=?"/>
        </login-module>
    </authentication>
</security-domain>

После чего вносим изменения в jboss-web.xml

<jboss-web>
    <security-domain>java:/jaas/securityexampledomain</security-domain>
</jboss-web>

сохраняем и перезагружаем сервер.

 

Шаг 3. Создание записей в базе

Теперь, нужно добавить пользователей в БД, для того чтобы мы смогли пройти аутентификацию.

INSERT INTO accounts VALUES (1, 'manager', 'manager', 'MANAGER');
INSERT INTO accounts VALUES (2, 'admin', 'admin', 'ADMIN');
INSERT INTO accounts VALUES (3, 'user', 'user', 'USER');

 

Шаг 4. Проверка работы безопасности

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

@WebServlet(urlPatterns = "/servlet2")
@ServletSecurity(httpMethodConstraints = {
        @HttpMethodConstraint(value = "GET", rolesAllowed = "MANAGER"),
        @HttpMethodConstraint(value = "POST", rolesAllowed = "MANAGER")
})
public class SecuredServlet2 extends HttpServlet{
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
                                                 throws ServletException, IOException {
       //body.....
    }
}

После чего вы увидите сообщение успешного доступа к защищенному контенту.

You are on secured page!

Урок создан: 12 июля 2014 | Просмотров: 14122 | Автор: Олег Криль | Правила перепечатки


Добавить комментарий

Добавить комментарий

Ваш e-mail не будет опубликован.

Комментарии:

  • 13 июля 2014 в 19:01

    Олег

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

    • 14 июля 2014 в 16:27

      Александр Барчук

      Это безопасно, так как не разработчик отвечает за данные пользоватлей, а человек который администрирует сервер. Но тут две стороны есть плюсы есть минусы.

      • 14 июля 2014 в 19:23

        Олег

        Вот у меня и вызывают сомнения то, что я со стороны разработки лезу в поле работы системного администратора… Спасибо за ответ, я как бы вижу и плюсы и минусы, меня больше интересовало используют ли такое решение в коммерции…

  • 02 августа 2014 в 20:03

    Дима

    А как реализовать авторизацию и аутентификация, если пользователи хранятся в базе ActiveDirectory?

  • 10 июня 2016 в 12:28

    Али

    Александр, было бы классно указать про возможность хеширования пароля, а то хранить пароль в не зашифрованном виде в базе не комильфо.

  • 25 октября 2016 в 14:02

    Алексей

    Не получается за пустить. пишет ошибка
    13:39:47,749 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-10) JBAS014613: Operation («test-connection-in-pool») failed — address: ([
    («subsystem» => «datasources»),
    («data-source» => «DataSourceEx»)
    ]) — failure description: «JBAS010440: failed to invoke operation: JBAS010442: failed to match pool. Check JndiName: java:jboss/datasources/DataSourceEx»