Java EE 6 Программная безопасность, стеклянная рыба и область JDBC

Question

Я изучаю чистые Java EE способы обеспечения безопасности программ, особенно пользователей входа, основанных на области jdbc с моего сервера Glassfish.

Так в основном, на мой логин сервлета Я делаю

String username = request.getParameter("username"); 
String password = request.getParameter("password"); 

try { 
    request.login(username, password); 
.... 

Не делая ничего в моей web.xml, используется область по умолчанию (файл). Я не хочу этого, я хочу использовать свой jdbcRealm с именем jdbcsecurerealm.

Так я добавляю следующее моей web.xml

<login-config> 
    <auth-method>FORM</auth-method> 
    <realm-name>jdbcsecurerealm</realm-name> 
</login-config> 

Обратите внимание, что я не добавить любую форму-логин-конфигурации для определения форм-входа-страницы и форм-ошибки-страницы.

Тогда, если я определить ограничения безопасности, такие как

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>Admin Pages</web-resource-name> 
     <description></description> 
     <url-pattern>/admin/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>administrator</role-name> 
    </auth-constraint> 
</security-constraint> 

хорошо ... это работает! Request.login проверяет мой jdbcRealm, и если я попытаюсь получить доступ к защищенным страницам без входа в систему, я получаю хороший 403.

Но, похоже, я смешиваю декларативную безопасность и программную безопасность, потому что чувствую что я не должен декларировать что-либо внутри web.xml, а скорее использовать request.isUserInRole.

Вопрос:

Может ли я ударяя GlassFish определенного поведения, или он может использовать программную безопасность (request.login) с определенной областью JDBC внутри web.xml без форм-вход-конфигурации?

Update Я только что видел, что есть возможность указать область внутри GlassFish-application.xml, это лучший подход к построению уха вместо войны для того, чтобы указать область?

Answer 1

Чистый программный подход в переносном (чистый Java EE) пути невозможен, когда вы используете специфичные для входа (собственные) модули входа в систему, такие как модуль входа/область входа в систему JDBC GlassFish.

Существует API в Java EE 6 для этого: JASPIC. С помощью этого API (SPI технически) вы можете создавать портативные модули аутентификации и настраивать их полностью программно без необходимости в каком-либо объявлении.

Я написал об этом blog article, который, надеюсь, предоставит вам более подробную информацию.

Answer 2

В веб-приложениях есть два аспекта безопасности: аутентификация и авторизация. Что вы используете здесь, является программным Аутентификация (способ входа пользователя) и декларативный авторизация (определяя, что пользователям разрешено видеть). Нет проблемы с смешиванием обоих, на мой взгляд.

Если вы держите свое царство в своем web.xml, ваше приложение будет более портативным. (это означает, что вы можете развернуть свою войну, например, на сервере tomcat без изменений).