2015-02-26 2 views
0

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

Найдено ниже до сих пор.

  1. Full Authorization Page Пример: <intercept-url pattern="/user/**" access="hasRole('ROLE_USER')" />
  2. встраиваемое Авторизация

    пример: <security:authorize access="hasRole('ROLE_ADMIN')">

  3. Метод авторизации на уровне - @PreAuthorize,@PostAuthorize,@PreFilter,@PostFilter

Я не уверен, если го является исчерпывающим списком для защиты приложения. Нужна помощь для этого. Благодарю.

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

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

ответ

2

Возможно, вам нужно будет начать с определения требований вашей модели домена, то, что считается конфиденциальными данными, а что нет и как эти данные доступны (HTML/JSP vs. REST/JSON vs direct Java calls). Затем используйте функции авторизации по мере необходимости. Ваш список содержит довольно много, что большинство приложений будет когда-нибудь понадобится, но для более тонкой и более продвинутых механизмов авторизации взглянуть на ACL Спринга:

http://docs.spring.io/spring-security/site/docs/3.0.x/reference/domain-acls.html

Еще один важный вопрос, который вы можете захотеть ответить себе, это какой слой приложения будет отвечать за обеспечение вашей безопасности: MVC/REST vs Services (рассеивание этой проблемы на нескольких уровнях обычно плохое). Это будет напрямую диктовать выбор функций SS, которые вы собираетесь сделать.

Возможно, вы захотите создать свои собственные аннотации поверх аннотаций SS, которые точно отражают ваш конкретный домен. Таким образом, вся сложность будет сосредоточена в одном месте, оставляя меньше места для ошибок.

Например, вы можете создать пользовательскую аннотацию, такую ​​как @AuthorizedFor, где вы можете добавить различные параметры для домена. Затем вы можете аннотировать эту аннотацию одной из аннотаций SS, скажем @Pre/PostAuthorize("hasAnyRole()") (здесь вы также можете играть с родным EL EL Spring для дальнейшей настройки поведения) и использовать собственную реализацию Pre/PostInvocationAuthorizationAdvice, где вы принимаете решения о авторизации на основе ваших пользовательских параметров аннотации. Дополнительное преимущество здесь заключается в том, что вы сможете обеспечить полное выполнение классов с помощью своей пользовательской аннотации вместо того, чтобы комментировать все методы в этом классе. В вашей реализации вы получаете экземпляр MethodInvocation, из которого вы можете опросить класс, содержащий этот метод, и посмотреть, если его аннотировать, а затем продолжить, как если бы сам метод был аннотирован.

Смотрите эту статью для более глубокого обсуждения: http://blog.novoj.net/2012/03/27/combining-custom-annotations-for-securing-methods-with-spring-security/

+0

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

1

Есть в основном 2 способа реализации пружинной безопасности. через конфигурацию компонента в .xml-файлах и других с помощью аннотаций. Метод, основанный на аннотации, прост в использовании в долгосрочной перспективе, поскольку он менее двусмыслен.

вот ссылка на spring.io. Оба способа объясняются красиво.

http://spring.io/blog/2013/07/03/spring-security-java-config-preview-web-security/

Аннотация чисто ява конфигурация на основе и, скорее всего, обгонит конфигурации XML.

+0

Спасибо. Аннотации мне интересны. Существуют ли аннотации, которые можно настроить? Например, я предоставил аннотации безопасности уровня метода, где вы предоставляете параметры - например, роли пользователей, которые имеют привилегии для доступа к методу или для доступа к элементам, возвращаемым методом. – Zack

+0

Это в основном уровни безопасности. Для меня я начинаю с защиты URL для разных ролей, поскольку сетка объясняет, что уровень безопасности уровня - это безопасность второго уровня и более безопасная. Эти слои прекрасно работают вместе, пока они не противоречат друг другу, что делает метод недоступным. http://www.concretepage.com/spring/spring-security/preauthorize-postauthorize-in-spring- безопасный уровень безопасности уровня безопасности простой пример. – Kharoud

1

Три элемента в списке служат для разных целей:

  1. перехватывать-URL: Добавляет безопасность сервлета слоя. Другими словами, вы контролируете, кто может/не может получить доступ к URL-адресу вашего приложения. Например, вы можете добавлять разрешения только администраторам для доступа к URL-адресу /admin/some_critical_operation, но разрешать всем пользователям, прошедшим проверку подлинности, доступ к /some_informational_page. Можно защитить ваше приложение только этим типом авторизации, но это очень хрупкий дизайн. Добавление или изменение URL-адресов может легко нарушить безопасность без уведомления.

  2. Авторизация на странице: это не настоящая авторизация, а только удобный тег для скрытия содержимого html, не предназначенного для текущего пользователя. Например, пользователь, не являющийся администратором, не должен видеть кнопку create new user. Как я уже сказал, это не реальная мера безопасности, поскольку пользователь может ввести URL-адрес в браузере и получить доступ, если ни один из других типов авторизации не был применен.

  3. Метод Level Authorization: добавляет безопасность в сервисный уровень. Это означает, что вы можете применять ограничения на то, кто может/не может вызвать метод некоторого класса обслуживания. Считается более безопасным и сложнее скомпрометировать, поскольку он применяется глубже в стеке прикладного уровня. Он может применяться как с аннотациями, так и с пространством имен безопасности.

Обычно вы начинаете с защиты своего приложения на сервисном уровне, а затем добавляете некоторый контроль URL-адреса. Добавление тегов авторизации на страницах необязательно.

+0

Спасибо. Итак, w.r.t весенние аннотации безопасности, я упомянул некоторые для авторизации уровня метода. Обеспечивает ли весенняя безопасность аннотации, которые могут использоваться в других местах, помимо авторизации на уровне метода? – Zack

+0

нет соответствующих аннотаций для защиты URL-адресов, если вы имеете в виду этот afaik. В некотором роде вы можете взломать это путем аннотирования методов контроллера, но это не рекомендуется, так как есть несколько проблем (см. Http://www.javatronic.fr/articles/2014/03/15/method_level_security_with_spring_security_and_spring_mvc.html). С другой стороны, вы можете избежать xml, применив java config. см. этот пример в весеннем справочнике: http://docs.spring.io/spring-security/site/docs/3.2.6.RELEASE/reference/htmlsingle/#authorize-requests – grid

1

пока не могу комментировать, но по поводу вашего вопроса:

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

Вы можете сами писать свои собственные аннотации, которые, в свою очередь, аннотируются с помощью аннотаций Spring Spring Security. Это делает их существенно расширением для домена. Тем не менее, стандартные аннотации SS позволяют использовать SpEL, который является довольно гибким, даже жестким, не связан с вашим конкретным доменом. Вы можете легко утверждать, что пользователь имеет определенные роли (GrantedAuthority) и т. Д.

Если вы хотите реализовать свои собственные аннотации, см. Ссылку в моем другом ответе для подробного обсуждения.

Я могу привести конкретный пример из недавнего проекта, над которым я работал.У нас были группы авторизации, управляемые внешней системой, а также встроенная логика, которая определяет доступ к определенным ресурсам. Итак, по существу у нас было 2 места для поиска параметров авторизации. Мы создали концепцию групп авторизации (извлекаемых извне через LDAP) и роли авторизации (встроенная бизнес-логика). Группы были простыми - если пользователь является членом группы, им предоставляется доступ, а другой - отрицается. С ролями у нас были бизнес-правила, определяющие, имеет ли пользователь определенную роль или нет (например, подписанный T & C, принятый EULA и т. Д.). Все они определяются на этапе аутентификации.

Чтобы упростить рассуждение о нашем контроле доступа, мы создали две аннотации @AuthorisedForGroups({group1, group2, ...}) и @AuthorisedForRoles({role1, role2,...}). Каждый из них, в свою очередь, был аннотирован родной весной @PreAuthorize("hasAnyRole()"). Обратите внимание на использование «hasAnyRole()» - это просто рассказать весне «пусть все, кто аутентифицирован», и что «мы сами будем принимать решения о авторизации». Решения авторизации Затем выполняется в пользовательской реализации PreInvocationAuthorizationAdvice (на самом деле мы просто расширить собственную реализацию Spring в ExpressionBasedPreInvocationAdvice) и поставить логику принятия решений в #before() методы:

@Override 
    public boolean before(Authentication authentication, MethodInvocation mi, PreInvocationAttribute attr) { 
     // 1) get AuthorisedForGroups & AuthorisedForRoles for the method 
     // 2) if either is missing from the method, check the enclosing class 
     // 3) if no annotations found - simply return super.before(...) 
     // 4) else, introspect the 'authentication' and see if it has the required groups/roles 
     // - here you may want to use 'ExpressionBasedAnnotationAttributeFactory' to 
     // create your own expressions which you then pass to super.before(...). 
     // This especially makes sense when your groups/roles 
     // are mapped to GrantedAuthority instances - as it was the case with our code. 


    } 

Надеется, что это помогает.

+0

Можете ли вы объяснить, как мои пользовательские аннотации становятся специфичными для домена ? Я не понял этот термин. В какой области мы имеем дело? – Zack

+0

От «домена» Я имею в виду ваш конкретный ** бизнес-домен **. См. Http://en.wikipedia.org/wiki/Business_domain & http://en.wikipedia.org/wiki/Business_model. В вашем контексте это означает, что вы создаете аннотации, которые предназначены для решения проблем вашей бизнес-модели. Когда это хорошо спроектировано, такой подход приведет к концентрации сложности в одном месте, делая остальную часть кода более читаемой и легче рассуждать. –

+0

Да. Я хотел понять термин домена в контексте аннотаций, о которых мы говорим. Я благодарю вас за ответ. Но я думаю, было бы здорово, если бы вы приводили пример использования аннотаций, предназначенных для решения проблем в бизнес-модели. Большинство этих аннотаций, с которыми я столкнулся до сих пор, проверяют наличие ролей или привилегий, которые определяются бизнес-требованиями. – Zack

Смежные вопросы