пока не могу комментировать, но по поводу вашего вопроса:
Есть аннотации, которые настраиваются? Например, я предоставил аннотации безопасности уровня метода, где вы предоставляете параметры - например, роли пользователей, у которых есть привилегии для доступа к методу или для доступа к элементам, возвращаемым методом
Вы можете сами писать свои собственные аннотации, которые, в свою очередь, аннотируются с помощью аннотаций 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.
}
Надеется, что это помогает.
Спасибо. Я ищу функции безопасности, которые можно легко реализовать и настроить, где разработчики с меньшей вероятностью допущают ошибки и в то же время достигают требуемых целей безопасности. – Zack