我的团队正在JAX-RS中设计一个RESTful API,我们需要根据经过身份验证的“Operator”(我们的User for User)的ID来限制数据库中某些行的可用性.换句话说,操作符应该只能访问其管辖范围内的实体.在每个请求开始时,我们对发出请求的操作符进行身份验证,允许我们根据操作符的角色和ID提供安全功能.

授权端点,端点方法甚至实体内容(被序列化的内容)已被证明相当简单,但行级授权似乎是一个巨大的毛茸茸的野兽.

请注意,我们没有使用Spring,也没有计划在我们的项目中使用Spring Security.

我们已经提出了一些可能的解决方案,但我们不确定哪种解决方案最好.我们还没有考虑过一个解决方案;此时我对任何事情持开放态度.这是我们到目前为止所得到的：

>数据库级实现(如this post中所述).这可能涉及使用请求的安全上下文在每个请求时将运算符的ID传递给数据库.我不清楚实现这种方法的细节,所以如果这是行级安全的最佳方法,我会很感激一些进一步的建议.例如,这对于实体检索是如何工作的有意义,但是我们如何修改新创建或更新的实体的行级权限？
> JPA级别的实施(如2008年的this post所述).这可能涉及生成参数化的Hibernate过滤器,我们将向其提供发出请求的运算符的ID.我从来没有使用过Hibernate过滤器,所以很有可能这个想法是非基础的.
>门面水平实施.我们实际上已经给出了这个想法,因为我们直到最近才意识到选项(1)和(2).这将涉及在我们的表之间执行连接以构造Criteria API谓词,该谓词将限制我们的查询仅包括给定运算符可访问的那些实体.就我的理解而言,这基本上是“手动”方法,似乎远非理想.

如果熟悉JAX-RS和/或数据库安全性的人可以帮助理解所有这些,那将是非常棒的.

这是我们的项目技术堆栈(至少与此问题相关)：

>数据库：MS SQL
> JPA Provider：Hibernate
> JAX-RS实现：RESTEasy

解决方法:

使用SQL Server 2016：行级安全性(RLS)是一种在数据库层的行级而不是应用程序层提供安全性的概念. RLS是通过使用函数和使用SQL Server 2016推出的新安全策略功能来完成的.(如果您确实需要行级安全性)