Question

我是Spring安全框架的新手。我只是编写了使用Spring安全注释或Spring安全框架添加安全功能的各种方法。

到目前为止找到了以下内容。

全页授权例如：<intercept-url pattern="/user/**" access="hasRole('ROLE_USER')" />
页内授权

示例：<security:authorize access="hasRole('ROLE_ADMIN')">
方法级别授权 - @PreAuthorize,@PostAuthorize,@PreFilter,@PostFilter

我不确定这是否是确保申请安全的详尽清单。需要一些帮助。感谢。

此外，我正在寻找可以轻松实现和配置的安全功能 - 开发人员不太可能犯错并同时实现所需的安全目标。看起来注释易于使用且不那么模糊。注释仅用于方法级别授权吗？ Spring安全性是否提供可用于保护应用程序其他部分的注释，这些注释是否可以传递参数来配置权限或权限？

我希望我的问题不是太宽泛。任何编辑或有用的评论将不胜感激。

Answer 1

也许您需要首先确定您的域模型的要求，什么是敏感数据，以及什么不是以及如何访问这些数据（HTML / JSP与REST / JSON对比直接Java调用）。然后根据需要使用授权功能。您的列表几乎包含大多数应用程序所需的内容，但是对于更精细和更高级的授权机制，请查看Spring的ACL：

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

您可能想要回答的另一个重要问题是哪个应用程序层将负责强制执行您的安全性：MVC / REST与服务（在多个层中分散这个问题通常是个坏主意）。这将直接决定您要制作的SS功能的选择。

您可能希望在SS注释之上构建自己的注释，这些注释会反映您的特定域。这样，所有复杂性都集中在一个地方，从而减少了出错的空间。

例如，您可以创建自定义注释，例如@AuthorizedFor，您可以在其中添加各种特定于域的参数。然后，您使用SS注释之一注释此注释，例如@Pre/PostAuthorize("hasAnyRole()")（此处您还可以使用Spring的原生EL来进一步自定义行为）并使用Pre/PostInvocationAuthorizationAdvice的自定义实现根据您的自定义注释参数做出授权决策。这里的附加优势是，您将能够使用自定义注释保护完整的类，而不必注释该类中的所有方法。在您的实现中，您将获得MethodInvocation实例，您可以从该实例查询包含该方法的类，并查看其是否已注释，然后继续执行 - 如果方法本身已注释。

有关更深入的讨论，请参阅此文章：http://blog.novoj.net/2012/03/27/combining-custom-annotations-for-securing-methods-with-spring-security/

Answer 2

实现弹簧安全性基本上有两种方法。通过使用Annotations在.xml文件和其他文件中进行bean配置。基于注释的方法易于长期使用，因为它不那么模糊。

这里是对spring.io的引用。两种方式都很好地解释了。

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

Annotation是基于纯Java的配置，很可能超过xml配置。

Answer 3

列表中的三个项目有不同的用途：

intercept-url：在servlet层添加安全性。换句话说，您可以控制谁可以/不能访问您的应用程序中的任何URL。例如，您可以仅向管理员添加权限以访问网址/admin/some_critical_operation，但允许所有经过身份验证的用户访问/some_informational_page。只有这种类型的授权才能保护您的应用程序，但它的设计非常脆弱。添加或更改网址很容易破坏安全性，恕不另行通知。
页内授权：它不是真正的授权，只是隐藏不适合当前用户的html内容的便利标签。例如，非管理员用户不应该看到按钮create new user。正如我所说，这不是真正的安全措施，因为如果没有其他任何授权类型被应用，用户可以在浏览器中输入网址并获得访问权。
方法级别授权：向服务层添加安全性。这意味着您可以对谁可以/不能调用某个服务类的方法应用限制。它被认为更安全，更难以妥协，因为它在应用层堆栈中应用得更深。它既可以应用于注释，也可以应用于安全命名空间。

通常，您首先将应用程序保护在服务层中，然后再添加一些URL控件。在页面中添加授权标签是可选的。

Answer 4

我还不能评论，但关于你的问题：

是否有可配置的注释？例如，我提供了方法级安全注释，您可以在其中提供参数 - 例如具有访问方法权限的用户的角色或访问方法返回的元素

您可以自由编写自己的注释，然后使用本机Spring Security注释进行注释。这使它们本质上是特定于域的扩展。也就是说，标准SS注释允许使用SpEL，这是相当灵活的，即使很难也不会绑定到您的特定域。您可以轻松断言用户是否具有某些角色（GrantedAuthority）等...

如果您想要实现自己的注释，请参阅我的其他答案中的链接以进行全面讨论。

我可以从最近的一个项目中给你一个具体的例子。我们有由外部系统管理的授权组以及定义对某些资源的访问的内置逻辑。所以，基本上我们有2个地方可以查找授权参数。我们创建了授权组（通过LDAP从外部检索）和授权角色（内置业务逻辑）的概念。这些组很简单 - 如果用户是该组的成员，则他们被授予访问权限，否则被拒绝。通过这些角色，我们制定了业务规则来确定用户是否具有特定角色（例如，签名的T＆amp; C，接受的EULA等等）。所有这些都在认证阶段确定。

为了更容易推理我们的访问控制，我们创建了两个注释@AuthorisedForGroups({group1, group2, ...})和@AuthorisedForRoles({role1, role2,...})。其中每一个都用Spring的本地@PreAuthorize("hasAnyRole()")注释。注意使用＆＃34; hasAnyRole（）＆＃34; - 这只是告诉Spring＆＃34;让所有经过身份验证的人都能在＃34;那个＆＃34;我们将自己做出授权决定＆＃34;。然后，在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. 


    }

希望这会有所帮助。

使用Spring安全框架实现安全性的不同方法

4 个答案: