Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > Spring Security

Автор: Eric_Cartman 8.9.2009, 14:02

Можно ли каким-то образом специфицировать (хранить, обрабатывать) "перехватываемые URL" не в *.xml файлах, к примеру

Код


<http use-expressions="true">
    ...
    <intercept-url pattern="/secure/extreme/**" access="hasRole('ROLE_SUPERVISOR')"/>
    ...
</http>

а в БД?

Еще может кто посоветует откуда начинать копать про spring security и role-based access control?

Автор: MisterCleric 8.9.2009, 14:09

Цитата

Еще может кто посоветует откуда начинать копать про spring security и role-based access control?

Я учился по референсу, который идет с дистрибутивом. Почитал, в проект прикрутил, уже два месяца как заказчик работает в приложении - не жалуется.

по поводу хранения в БД, что именно надо хранить?

ЗЫ: а что за use-expressions ?

Автор: Eric_Cartman 8.9.2009, 14:18

Цитата(MisterCleric @ 8.9.2009, 14:09)

по поводу хранения в БД, что именно надо хранить?

ЗЫ: а что за use-expressions ?

В БД хранить связку "паттерн URL, кот. перехватывается фильтром spring security" - "authority в терминах того же SS", не просто хранить а сделать так, чтобы SS эти связки подцеплял из БД а не из xml. Это вообще реально?

use-expressions - без понятия =) Скопипастил из мануала просто кусок xml.

Добавлено @ 14:20

Еще может кто посоветует откуда начинать копать про spring security и role-based access control?
Этот вопрос я неправильно немного задал, он скорее звучт так:
как при помощи SS реализовать концепцию "role-based access control"?

Автор: MisterCleric 8.9.2009, 14:57

дык это ж и решается через:

Код


<intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/>
<intercept-url pattern="/theme/**" filters="none"/>
<intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/>

Вообще, ты можешь создавать бины не в xml, а ручками из java-кода.
Вот вопрос: зачем так заморачиватся? Ведь суть контейнера как раз в том, что сначала подымается он, а потом уже через него конфигурится поведение приложения

Автор: Eric_Cartman 8.9.2009, 15:10

Цитата(MisterCleric @ 8.9.2009, 14:57)

дык это ж и решается через:

Код


<intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/>
<intercept-url pattern="/theme/**" filters="none"/>
<intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/>

Да, я в курсе, что это так и решается.

Вопрос был как раз в том, можно ли это решить не через xml, а через базу. Зачем это нужно: для динамического (почти динамического) изменения пермишенов на УРЛы.

К примеру, у меня была такая связка

Код


<intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/>

Я хочу к этому же паттерну добавить еще одну роль, скажем ROLE_SATANA, мои действи: я правлю xml следующим образом

Код


<intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE, ROLE_SATANA"/>

и передеплоиваю приложение. Все правильно расписал?

Так вот, вопрос в том, есть ли возможность делать подобные вещи не передеплоивая приложения? (я предположил что есть возможность делать это через базу, только вопрос "как")

Автор: ker_tt 8.9.2009, 16:08

Да, вопрос интересный.
Сам недавно копал на эту тему - в теории все более-менее понятно, но писать самому нет времени, а в виде готовых примеров к сожалению ничего не нашел.
Так что если кто-то кинет готовый пример - будет просто замечательно.

Автор: MisterCleric 8.9.2009, 17:26

Ребята, я такие вещи решал на уровне прав.
Есть такой паттерн:

Код


<intercept-url pattern="/**" access="IS_AUTHENTICATED_REMEMBERED"/>

Потом есть в базе столько угодно ролей, которые могут динамически создаваться и удаляться. И, соответственно, им назначаются определенные права. А вот можно ли пользователю заходить на тот или иной ресурс уже проверяется или на уровне

Код


<security:authorize ifAllGranted="...">

Или проверкой присутствия соответствующего права у данной роли:

Код


  <rich:column id="deleteColumn" rendered="#{rolesManager.rightIdsByPrincipal['18'] != null}">

Я ж так понимаю, если добавляются какие-то новые ресурсы в закрытом для определенной роли контексте, то все-равно приложение передеплоивается...

Автор: MisterCleric 9.9.2009, 09:06

Доброе утро. Еще дочитал такое:

Цитата

access-decision-manager-ref
Optional attribute specifying the ID of the AccessDecisionManager implementation which should be used for authorizing HTTP requests. By default an AffirmativeBased implementation is used for with a RoleVoter and an AuthenticatedVoter.

Надо поковырять в сторону кастомизации ADM, что бы он проверял реквест паттерн на то, что у тебя есть в базе

Автор: MisterCleric 9.9.2009, 10:17

Так, и читаем еще здесь:
http://static.springsource.org/spring-security/site/faq.html#faq-dynamic-url-metadata

Автор: MisterCleric 9.9.2009, 10:52

Ну, в общем, ребята, меня это тоже зацепило. Решил побороть такую задачу.
Делаем где-то так:

Код


 <http access-decision-manager-ref="dbAccessDecisionManager">
        <intercept-url pattern="/**" access="IS_AUTHENTICATED_REMEMBERED"/>
    </http>

    <beans:bean id="roleVoter" class="org.springframework.security.vote.RoleVoter"/>
    <beans:bean id="dbRoleUrlVoter" class="DbRoleUrlVoter"/>
    
    <beans:bean id="dbAccessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
    <beans:property name="decisionVoters">
      <beans:list>
        <beans:ref local="roleVoter"/>
        <beans:ref local="dbRoleUrlVoter"/>
      </beans:list>
    </beans:property>
  </beans:bean>

Где DbRoleUrlVoter имеет метод:

Код


public int vote(Authentication authentication, Object object, ConfigAttributeDefinition config)
  {
    if ((object == null) || !this.supports(object.getClass()))
    {
      throw new IllegalArgumentException("Does not support the presented Object type");
    }
    
    GrantedAuthority[] authorities = authentication.getAuthorities();
 
    FilterInvocation invocation = (FilterInvocation) object;
    HttpServletRequest request = invocation.getHttpRequest();
    
}

1. При инициализации данный бин достает роли и паттерны урлов из базы.
2. Ловит событие смены ролей-паттернов, что бы перегрузить свой локальный кеш.
3. Из request можно достать УРЛ и наложить его на имеющийся паттерн.
4. authorities содержит роли текущего юзера.

Не проверял, конечно, но мне кажется логично.