Java中的动态代码评估-聪明还是草率？

我正在尝试为我的应用程序在Java中创建一个灵活的ACL框架。

许多ACL框架都建立在规则白名单上，其中规则的形式为owner：action：resource。例如，

• “ JOHN可以查看资源FOOBAR-1”
• “ MARY可以查看资源FOOBAR-1”
• “ MARY可以编辑资源FOOBAR-1”

这很有吸引力，因为规则可以轻松地序列化/持久化到数据库。但是我的应用程序具有复杂的业务逻辑。例如，

• “部门1中具有5年以上资历的所有用户都可以查看资源FOOBAR-1，否则未经授权”
• “部门2中的所有用户，如果日期是2016年3月15日之后，则可以查看资源FOOBAR-2，否则未经授权”

乍一想，设计一个可以处理无限复杂规则的数据库模式将是一场噩梦。因此，似乎我需要将它们“烘焙”到编译的应用程序中，为每个用户评估它们，然后根据评估结果生成owner：action：resource规则。 我想避免将逻辑烘焙到已编译的应用程序中。

因此，我正在考虑以谓词：action：resource的形式表示规则，其中谓词是确定是否允许用户的布尔表达式。该谓词将是Java的Rhino引擎可以评估的JavaScript表达式的字符串。例如，

• return user.getDept() == 1 && user.seniority > 5;

这样，可以轻松地将谓词保存到数据库中。

这很聪明吗？这是草率的吗？这是花哨的吗？这是过度设计的吗？这样安全吗（显然，Java可以将Rhino引擎沙箱化）。

将动态数据插入实现语言的解释器中通常不是一个好主意，因为它将数据损坏的可能性升级为恶意应用程序接管的可能性。换句话说，你自己的方式走出去创造一个代码注入漏洞。

您可以通过规则引擎或特定领域语言（DSL）更好地解决您的问题。看看这些概念，就不需要重新发明轮子了。

我这样做了，建议您不要这样做。

我所做的就是在Lua中编写所有业务逻辑，并将该Lua脚本存储在数据库中。当我的应用程序启动时，它将加载并执行脚本。这样，我可以在不分发新二进制文件的情况下更新应用程序的业务逻辑。

我总是发现进行更改时总是需要更新二进制文件。Lua脚本中有一些更改，但是我总是要进行一系列更改，因此我几乎总是最终不得不对二进制文件进行某些更改以及在Lua脚本中进行一些更改。我一直无法避免分发二进制文件的想象并没有成功。

我发现更有用的是简化二进制文件的分发。我的应用程序会在启动，下载和安装任何更新时自动检查更新。因此，我的用户始终使用我推送的最新二进制文件。二进制文件的更改和脚本的更改之间几乎没有区别。如果我再做一次，我将付出更多的努力来使更新无缝进行。

我不会在数据库中包含代码。但是您可以通过使数据库包含函数名称，然后使用反射来调用它们来执行类似的操作。添加新条件时，必须将其添加到代码和数据库中，但是可以组合传递给它们的条件和参数来创建非常复杂的评估。

换句话说，如果您已为部门编号，则很容易进行UserDepartmentIs检查和TodayIsAfter检查，然后将它们合并为Department = 2和Today> 03/15/2016。如果然后要进行TodayIsBefore检查，以便可以在权限结束日期之前，则必须编写TodayIsBefore函数。

我尚未针对用户权限执行此操作，但已针对数据验证执行了此操作，但它应该可以工作。

XACML是您真正想要的解决方案。它是一种规则引擎，仅专注于访问控制。XACML是OASIS定义的标准，它定义了三个部分：

• 建筑
• 一种策略语言（这确实是您想要的）
• 请求/响应方案（您如何请求授权决定）。

架构如下：

• 策略决策点（PDP）是体系结构的核心部分。它是根据一组已知策略评估传入授权请求的组件
• 策略执行点（PEP）是保护您的应用程序/ API /服务的代码段。PEP拦截业务请求，创建XACML授权请求，将其发送给PDP，接收回响应，并在响应内部执行决策。
• 策略信息点（PIP）是可以将PDP连接到外部数据源（例如LDAP，数据库或Web服务）的组件。当PEP发送请求时，例如“ Alice可以查看文档＃12？”时，PIP会派上用场。PDP的政策要求使用者的年龄。PDP将询问PIP“给我爱丽丝的年龄”，然后将能够处理这些政策。
• 策略管理点（PAP）是管理整个XACML解决方案（定义属性，编写策略和配置PDP）的地方。

这是您的第一个用例：

/*
 * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
 * 
 */
 policy departmentOne{
    target clause department == 1
    apply firstApplicable
    /**
     * All users in department 1 with over 5 years of seniority can VIEW resource FOOBAR-1, else not authorized
     */
    rule allowFooBar1{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }

 }

您的第二个用例是：

 /*
  * "All users in department 2, if the date is after 03/15/2016, can VIEW resource FOOBAR-2, else not authorized"
  *  
  */
  policy departmentTwo{
    target clause department == 1
    apply firstApplicable
    rule allowFooBar2{
        target clause resourceId=="FOOBAR-1" and seniority>=5 and currentDate>"2016/03/15":date and actionId=="VIEW"
        permit
    }
    rule denyOtherAccess{
        deny
    }
  }

您可以通过使用引用将两个用例组合到一个策略中：

  policyset global{
    apply firstApplicable
    departmentOne
    departmentTwo
  }

大功告成！

您可以从以下网站阅读有关XACML和ALFA的更多信息：

• XACML 开发人员的博客
• XACML开发人员的YouTube频道

您在这里真正想要的是XACML。它几乎可以为您提供所需的一切。您不必完全将所有角色完全分开来实现完整的体系结构...如果您只有一个应用程序，则可以通过balana将PDP和PEP集成到您的应用程序中，而PIP则可以您现有的用户数据库是。

现在，在应用程序中需要授权的任何地方，您都将创建一个XACML请求，其中包含用户，操作和上下文，XACML引擎将根据您编写的XACML策略文件做出决定。这些策略文件可以保存在数据库或文件系统中，也可以保存在任何要保留配置的地方。Axiomatics是XACML XML表示法ALFA的一个很好的替代方案，它比原始XML更易于阅读，并且有一个Eclipse插件可以根据ALFA策略生成XACML XML。

我们在我目前的公司中做到了这一点，我们对结果感到非常满意。

我们的表达式是用js编写的，我们甚至使用它们来限制用户通过查询ElasticSearch可以获得的结果。

诀窍是确保有足够的信息来做出决定，以便您可以真正编写所需的任何烫发而无需更改代码，但同时又要保持快速。

我们实际上并不担心代码注入攻击，因为权限是由不需要攻击系统的人编写的。像while(true)示例一样，这同样适用于DOS攻击。系统管理员不需要这样做，他们可以删除所有人的权限...

更新：

作为组织的中央身份验证管理点，诸如XACML之类的东西似乎更好。我们的用例略有不同，因为我们的客户通常没有IT部门来运行所有这些。我们需要一些自成体系的东西，但是试图保留尽可能多的灵活性。