VPF::Spring security VS Tomcat security - Форум программистов

garbuz

Дата 24.6.2009, 00:39 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 677
Регистрация: 22.1.2008

Репутация: 8
Всего: 11

Начал прикручивать тут к приложению Spring security, раньше обходился средствами томката. Вот какие вопросы возникли:

1) Родная для томката авторизация - это авторизация на сервере (используя какой-нибудь Realm), т.е. в рамках сервлет контейнера, автоматически создается какая-то сессия, создается объект userPrinsipals, авторизация в спринг секьюрити - это немного другая авторизация, можно наверно сказать, что это авторизация в контексте приложения, но не сервера. Я верно понимаю?

2) Используя аторизацию томката (позвольте я так буду ее называть), я в любое время мог вытащить из запроса объект Principal, из него получить имя пользователя и соответственно имея имя, мог получить все остальное. Как в спринг секьюрити с этим? Дело в том, что используя авторизацию спринга я вижу, что объект Principal из запроса все время равен null. Неужели надо создавать свой кастомный authentication-provider, в котором создавать сессию и класть в нее имя и все остальное?

3) В спринг секьюрити есть такая штука как default-target-url - это когда ты проходишь не по защищенной ссылке, а просто на страницу авторизации, так вот после успешной авторизиции тебя форварднет на default-target-url. Вопрос - в томкате есть аналог? Там как-нибудь можно определить такой же дефолтный url?

4) В томкате все было понятно с ролями, какие роли нарисовал в web.xml, такие и будут, у меня на данный момент две роли - admin и user. А в спринг секьюрити как я понял свои роли? Или я ошибаюсь? Дело в том, что есть в access вставить свои роли, то не катит - не заводится приложение. Если вставить типа ROLE_USER, ROLE_ADMIN, то все работает (заводится). Так вот, у меня в базе роли тоже должны быть под такими именами типа как ROLE_USER, ROLE_ADMIN? Или это не обязательно? Если кто-то подробнее расскажет о ролях с принге, буду очень признателен, особенно хотелось бы услышать про ANONYMOUS, там их как я видел несколько различных вариаций.

5) Хотелось бы выслушать предложения или советы как правильно организовать работу с пользователями, может кто расскажет как сам делал и т.п. У меня видимо до сих пор нет полной картины как это правильно делается, надо ли создавать сессию или нет, какие данные о пользователе там хранить и т.д. и т.п.

Спасибо.

NeoNYura

Дата 24.6.2009, 10:00 (ссылка)

(нет голосов)

Загрузка ...

Шустрый

Профиль
Группа: Участник
Сообщений: 60
Регистрация: 10.3.2008

Репутация: нет
Всего: нет

C Tomcat security не работал, а с Asegi чуть чуть возился

2)В Спринге

Код


SecurityContext con =(SecurityContext) request.getSession().getAttribute(HttpSessionContextIntegrationFilter.SPRING_SECURITY_CONTEXT_KEY);
(UserDetailsImp)con.getAuthentication().getPrincipal();

иногда SecurityContext возвращается null, можно попробовать еще вот так

Код


con=SecurityContextHolder.getContext();

4)Можно получить имя, права и т.д., Правда я писал свою авторизацию, но я думаю если она используется стандартная тоже будет работать.

Если не ошибаюсь у Спринга могут быть сколько угодно ролей, но они должны начинаться с ROLE_* ,

Если пишешь свое DAO на авторизацию, то можешь в нем из своих ролей в спринговые переделывать =)

5) писал, свою авторизацию с использованием спринга - что бы хранить больше данных о пользователе. Спринг сам пишет в сессию. И уже в обработке, я работаю по Роли юзера, вывожу нужную инфу.

MisterCleric

Дата 24.6.2009, 10:06 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1043
Регистрация: 16.2.2006
Где: Харьков, Украина

Репутация: 33
Всего: 38

привет. Попробую ответить на некоторые вопросы:
С томкат-секурити не работал сказать толком ничего не могу о нем.
1. По поводу userPrincipal вроде все правильно написал, а вот насчет того, что "спринг секьюрити" всего лишь авторизация в рамках приложения есть заблуждение. Это всего лишь одна из разновидностей поведения данного движка.
Спринг поддерживает также несколько серверных видов авторизации
   а) Java Authentication and Authorization Service (JAAS) Provider - когда инфа о юзерах и их ролях выбираетя из LoginModule, настроенного на сервере. В твоем случае это realm в томкат
   б) Pre-Authentication Scenarios - когда пользователь уже залогинен в системе, но наше приложение еще о нем не знает
   в) X.509 Authentication - авторизация через сертификаты
   г) CAS Authentication - сорри не разбирался с этим...
   д) Container Adapter Authentication - вот как раз то, что тебе надо. Цитата из refernce в spring-security-2.0.4 дистрибутиве

Цитата

Spring Security currently supports Jetty, Catalina (Tomcat), JBoss and Resin. Additional container adapters can easily be written

Я думаю, что досточно ответил на этот вопрос. Просто спринговский секурити это не логин-модуль, а движок для удобного управления авторизацией и уатентификацией в приложении. Не важно какой механизм авторизации ты используешь - у тебя есть одна абстракция на все. один раз приложение написал, а потом просто переключаешь механизмы авторизации (в спринг естественно) в собственное удовольствие
2. На первую часть этого вопроса думаю был ответ в моем первом ответе: если у тебя будет в спринг происходить делегированная авторизация в LoginModule, то естественно ты Principal в реквесте получишь. Но я считаю, что надо уже идти одним механизмом, поскольку не всегда авторизация идет через сервлеты, то спринг предлагает другой механиз доствания принципала:

Код


Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
GrantedAuthority[] authorities = authentication.getAuthorities();

3. Заблуждение. default-target-url - это урла, куда перенаправлять после авторизации, если ее не указать, то перенаправление будет идти на тот защищенный ресурс, на который мы попытались ламануться неавторизованными. Пример таков: Ты удачно залогинился и бродишь по защищенным (т.е. тем которые требуют авторизации) страницам. Потом, перейдя на какую-то свою любимую страничку в этом приложении, (не дай бог!) случайно твоя сессия отваливается. AccessDecisionManager смотрит, что ты не залогинен и отправляет тебя на форму логина. Псоле чего переводит на ту страницу, с которой тебе пришлось валить на логин.

Пока все. На остальные вопросы чуть позже

--------------------

ПРИШЕЛ, УВИДЕЛ - ПЕРЕПИСАЛ...

MisterCleric

Дата 24.6.2009, 10:44 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1043
Регистрация: 16.2.2006
Где: Харьков, Украина

Репутация: 33
Всего: 38

Цитата

А в спринг секьюрити как я понял свои роли

Нет. Роли там не свои, а те которые ты сам придумаешь и где-то заскладируешь. Складируешь их в том виде, как тебе хочется например "ADMIN", а уже authentication-provider добавляет к ним префикс "ROLE_". Я, правда, дела авотризацию через LDAP и его ldap-authentication-provider можно указать свой префикс.
А потом ты пишешь типа такого в конфиге:

Код


        <s:intercept-url pattern="/secure/extreme/**" access="ROLE_ADMIN"/>
        <s:intercept-url pattern="/secure/user/**" access="ROLE_USER"/>
        <s:intercept-url pattern="/secure/**" access="IS_AUTHENTICATED_REMEMBERED" />

т.е. разграничиваешь доступ к ресурсам по ролям.
Про ANONYMOUS толком сказать ничего не могу - не пользовался, но в reference есть по этому поводу глава 17

5. Естественно, что сессия создается автоматом, и спринг туда ложит все, что надо по секурити. по поводу работы с пользователями - как тебе надо так и крути. Все пожелания возможно организовать. Я даже делал такую вещь, как проверка сессия на истечение. Короче заказчик попросил в админке сделать настройку, сколько минут может пользователь просто висеть. т.е. понятно, что в web.xml

Код


 <session-config>
        <session-timeout>60</session-timeout>
    </session-config>

редактировать низя, во и прешлось писать такое:

Код


<beans:bean id="checkExpirationSessionFilter" class="mycompany.web.spring.security.CheckExpirationSessionFilter"
                p:sessionRegistry-ref="_sessionRegistry">
        <custom-filter before="CHANNEL_FILTER"/>
    </beans:bean>

Код


public class CheckExpirationSessionFilter extends SpringSecurityFilter implements InitializingBean {
    protected static final Log log = LogFactory.getLog(CheckExpirationSessionFilter.class);
    private SessionRegistry sessionRegistry;

    @Autowired
    private SystemPropertiesManager systemPropertiesManager;

    protected void doFilterHttp(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpSession session = request.getSession(false);

        if (session != null) {
            SessionInformation info = sessionRegistry.getSessionInformation(session.getId());

            if (info != null) {
                Calendar c = Calendar.getInstance();
                c.add(Calendar.MINUTE, -systemPropertiesManager.getExpirationHttpSessionMinutes());
                Calendar lastRequestTime = Calendar.getInstance();
                lastRequestTime.setTime(info.getLastRequest());
                if (lastRequestTime.before(c)) {
                    log.debug("Expire session for: " + info.getPrincipal());
                    info.expireNow();
                }
            }
        }

        chain.doFilter(request, response);
    }

    public int getOrder() {
        return FilterChainOrder.CONCURRENT_SESSION_FILTER - 1;
    }

    public void afterPropertiesSet() throws Exception {
        Assert.notNull(sessionRegistry, "SessionRegistry required");
    }

    public void setSessionRegistry(SessionRegistry sessionRegistry) {
        this.sessionRegistry = sessionRegistry;
    }
}

Еще просили в той же админке показывать активные сессии и иметь возможность принудительно отключать пользователей и того вышло такое:

Код


public class SessionsPageBean implements InitializingBean {

    private HttpSessionManager sessionManager;
    private static final Log logger = LogFactory.getLog(SessionsPageBean.class);
    //    private HtmlDataTable dataTable;
    private String sessionId;
    private Object currentPrincipal;

    private List<SessionInformation> sessions;

    public List<SessionInformation> getSessions() {
        return sessions;
    }

    public void removeSession() {
        logger.debug("Remove session with id: " + sessionId);
        sessionManager.exceedSession(sessionId);
        sessions = sessionManager.getActiveSessions();
    }

    public void setSessionManager(HttpSessionManager sessionManager) {
        this.sessionManager = sessionManager;
    }

    /*public HtmlDataTable getDataTable() {
        return dataTable;
    }

    public void setDataTable(HtmlDataTable dataTable) {
        this.dataTable = dataTable;
    }*/

    public void setSessionId(String sessionId) {
        this.sessionId = sessionId;
    }

    public Object getCurrentPrincipal() {
        return currentPrincipal;
    }

    public void afterPropertiesSet() throws Exception {
        Assert.notNull(sessionManager, "sessionManager can't be NULL");
        currentPrincipal = SessionRegistryUtils.obtainPrincipalFromAuthentication(SecurityContextHolder.getContext().getAuthentication());
        logger.debug("Sessions length: " + sessionManager.getActiveSessions().size());
        sessions = sessionManager.getActiveSessions();
    }
}

думаю досточно.

--------------------

ПРИШЕЛ, УВИДЕЛ - ПЕРЕПИСАЛ...

garbuz

Дата 24.6.2009, 11:09 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 677
Регистрация: 22.1.2008

Репутация: 8
Всего: 11

NeoNYura, MisterCleric, большое спасибо за ответы smile

Буду рад выслушать еще чье-то мнение.

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Java EE (J2EE) и Spring \| Следующая тема »