Spring-Security: насколько разумна настройка? - PullRequest
Новая
       64

Spring-Security: насколько разумна настройка?

2 голосов
/ 20 сентября 2011

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

Мне интересно это, поскольку я думаю о способе реализации динамических списков ACL, которые предоставляют или отменяют основной доступ для одного объекта, а также для всех объектов этого типа или даже любого идентификатора String. Если я хочу быть в состоянии сказать 

@PreAuthorize("hasPermission(#person, details)")
public void getDetailsForPerson(Person person)

а также 

@PreAuthorize("hasPermission('package.path.Person', read)") 
public void getAllPersons()

а также 

@PreAuthorize("hasPermission('Person', read)") 
public void getAllPersons()

а также 

@PreAuthorize("hasPermission(#id, 'package.path.Person', read)")
public void getOnePerson(int id)

Мне придется реализовать PermissionEvaluator. Теперь, когда я нахожусь в этом, почему я должен использовать точную модель данных ACL с пружинной безопасностью (как описано в Справочном документе A.3 Spring Security Reference) вместо реализации моей собственной? В любом случае мне придется реализовать свой собственный ACLService, если я хочу разрешить оценку разрешений для типов объектов или строк, а также для экземпляров объектов.

То же самое для ObjectIdentity поисков: мне придется реализовать их самостоятельно, а также я хочу сгенерировать OID из @Entity s serialVersionUID, чтобы иметь возможность предоставлять доступ к разрешениям типа.

Так как я думаю о все большем количестве вещей, которые можно реализовать на заказ, мне интересно, все ли я на правильном пути. Глядя на учебники, такие как блог Denksoft . Я чувствую, что упускаю множество возможностей весенней безопасности, которые могут нам понадобиться позже. Или просто Spring-Security очень мощная и сложная на тот случай, если вам это нужно, но если вы хотите, вы можете сделать большую часть этого самостоятельно и просто использовать общую структуру, чтобы скрепить все это вместе?

Или я создаю потенциальные дыры в безопасности, не придерживаясь протестированных реализаций? Является ли то, что я имею в виду, уже опасным или приемлемым с точки зрения безопасности и разработки программного обеспечения, поскольку я придерживаюсь интерфейсов, предоставляемых Spring-Security? Я еще не настроил слишком много заданных реализаций ...

Итак ... Мы будем очень рады размышлениям о том, что мы планируем сделать (разрешения для типов и объектов), а также о настройке безопасности пружин.

Ура! 1034 * *

1 Ответ

2 голосов
/ 19 октября 2011

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

Короче говоря, мы в конечном итоге сделали пользовательскую реализацию всех защитных интерфейсов Spring, которые взаимодействуют с базой данных, для использования нашего собственного стека доступа JPA / Hibernate. Это означало реализацию

Аутентификация

  • CustomerDetailsService для обработки таблицы нашего счета
  • RoleHierarchy, чтобы разрешить нашу собственную таблицу иерархии (отношение 1: n к Role, которое имеет от m: n до Account)
  • PersistentLoginToken чтобы сохранить токен "запомнить меня" в нашей базе данных

Для нашего специального Списка контроля доступа , который также поддерживает настройку разрешений для всех объектов типа:

  • MutableAclService, Acl, AccessControlEntry и LookupStrategy для построения ACL
  • PermissionEvaluator для поддержки аргументов типа класса (в виде String)

Так что в целом довольно много работы, и есть некоторые вещи, в которых нашей реализации не хватает. Стоило ли? Конечно, сейчас у нас гораздо больше контроля, больше гибкости и новые функции. Это стабильно? Мы увидим, что пока 45 модульных тестов для пользовательских реализаций звучат как много, но на самом деле это не так.

...