Vic*_*nça 5 acl authorization node.js elasticsearch
我有一个使用NodeJS和Elasticsearch的系统(RESTful),该系统实现RBAC授权策略。RBAC授权与其他API之前的授权服务器一起使用,以针对授权给用户角色的路由对每个请求进行测试(使用承载令牌来认证用户)。
我喜欢这种设计,因为其他API不需要了解授权/身份验证服务。而且它非常非常非常快,因为它使用内存缓存策略,而不是每次收到新请求以测试auth时都向Elasticsearch发送请求。
但是现在我需要实现ACL,以提供对授权的更精细控制。从REST的角度来看,该策略将在资源级别应用。示例:“ POST:/ user / 123”仅授权给A用户。
我与客户进行了调查,其中85%只会使用ACL的允许策略,默认情况下,ACL控件将拒绝所有内容。好的,现在我掌握了开发此控件的所有信息。但是我看不到实现此目标的最佳方法。
我的第一个想法是:
系统最重要的质量是可伸缩性。
好的,这不可能在内存缓存中完成,我已经对100k用户和100万资源(可能是真实的情况)进行了一些模拟,并且内存量巨大,如果缓存,此功能将带来高昂的成本;
在这种情况下,身份验证服务无法处理ACL,因为它无法过滤搜索。auth服务不会截取结果,仅验证标头和针对角色的路由;
因此,就所有这些要点而言,如果在Elasticsearch的每个文档中都有一个名为“ acl_allow_method_user”的新字段,该字段是授权使用此资源的方法+用户ID的数组。最终会变成这样:
"acl_allow_method_user":["POST:123434"]
我还必须创建一个通用包,供所有API使用,以在每次与Elasticsearch进行交互时验证此策略,但是我看不到任何问题。
有ACL经验的人,这是一个好的设计吗?
Elasticsearch对数组字段的大小有限制吗?
性能如何?这种方法会产生影响吗?
我建议为 ACL 建立一个单独的 Elasticsearch 索引,该索引应该比主文档索引小得多。这将允许您适当调整 ACL 索引设置,例如 (1) 分片数量低于主文档索引,(2) auto_expand_replicas 设置为 0-all,以防您想使用术语查询(例如:加载用户拥有的所有文档),以及 (3) 实施不同的保留/GDPR 策略。
然后,ACL 索引可以包含每个 ACL 规则的文档,例如 userId=1、docId=123、opType=POST。请注意,此方法将允许您将来为其他类型的主体和资源定义 ACL 规则。此外,这可以支持可以动态匹配新文档的ACL,例如userId=1,opType=POST,pattern="*"将允许userId=1的用户发布任何文档,实际上是系统管理员。将 ACL 与文档/用户解耦将允许您更新 ACL,而无需更新相应的文档,这在 Elasticsearch 中表现更好,因为 Elasticsearch 不进行就地更新,而是删除并重新创建文档。此外,您可以替换(PUT)整个文档,而不必担心保留关联的 ACL。但是,您可能希望在删除文档或用户时清理 ACL,这可以在删除期间完成,也可以作为单独的计划清理过程来完成。
现在,ACL 与文档本身是分离的,它们可以缓存在 memcached 或 Redis 集群中,而不需要太多内存。在典型的 OLTP 系统中,任何时间点都只有一小部分用户处于活动状态,因此您可以适当配置 LRU 缓存以提高命中率。如果不知道您的系统的特征是什么类型的访问模式,就很难提供进一步的建议。
最后要考虑的一点是ACL 的生成因素。如果某些 ACL 是自动生成的(例如,基于某种模式),那么也许您可以在系统中使用此模式来避免每个用户每个文档都有一个 ACL 规则。例如,如果某些 ACL 是从目录服务生成的,那么您可能能够在 ACL 管理系统中缓存(并定期刷新)LDAP 规则。
| 归档时间: |
|
| 查看次数: |
1038 次 |
| 最近记录: |