2015-01-14 47 views
0

我们已经为隐式和显式角色设置了基于角色的身份验证和角色层次结构的spring安全项目。我们还需要根据域对象的状态提供不同的授权。例如:Spring安全ACL - 域状态更改

订单域对象:

  • 下订单时在初始状态
    • 字段1,2,3是由RoleA编辑,并通过RoleB
    • 字段4,5可见, 6是由RoleA和角色乙编辑
  • 当订单在QA状态
    • 字段1,2,3是由RoleA可见,并且通过RoleB
    • 字段4,5,6由角色A的可视和RoleB
  • 下订单时在完成状态
    • 字段1可编辑,图2,图3是由RoleA可见的,并且可查看由RoleB
    • 字段4,5,6是由RoleA和RoleB

标准弹簧安全可视我们使用ant匹配器的URL级别的安全性不足以处理授权要求,因为如果它们处于任何状态,相同的服务URL将用于查看(GET)并保存(PUT)订单域对象。我们还希望让流程可配置为每个权限集中的哪些字段。

春季域对象的安全看起来像它适用于其中的状态下被固定或恒定域对象 - 由特定用户创建的博客文章,等...
可这一要求被春域处理的对象安全,或这应该更好地处理自定义代码/配置?

回答

0

你是非常正确的。 Spring Security权限评估程序和ACL基础结构适用于域对象级别,而不是字段级别。你可以创建像EDIT_FIELD1,EDIT_FIELD2,VIEW_FIELD1等权限,但它感觉一点点强制。当然,您可以使用其他Spring Security基础结构和@PreAuthorize注释等,并使用您的自定义代码进行扩展。

如果您对用户有一定的信心并且被允许放松安全性,我会建议跳过现场级别,并且只对订单状态和角色进行评估。你可能想要一些审核日志记录谁在编辑什么。字段可以在用户界面中变暗以避免意外编辑。我已经看到了工作流应用程序的功能。

+0

感谢holmis,我并没有去个别领域的水平,而是看着一小群领域。您提出了我们将拥有的审计线索的一个好点。我还计划在调光领域。因为这是一个内部应用程序,并且我们有审核和暗淡的字段,所以我们不需要URL上额外的安全级别 – Vince