我有一个使用NodeJS和Elasticsearch实现RBAC授权策略的系统(RESTful)。RBAC授权与授权服务器一起工作,该服务器在其他API之前测试每个请求是否符合用户角色授权的路由(使用Bearer令牌对用户进行身份验证)。
我喜欢这个设计,因为其他API不需要知道授权/身份验证服务。而且它非常非常快,因为它使用内存缓存策略,而不是每次收到新请求时都向Elasticsearch发出请求来测试授权。
但现在我需要实现ACL以提供更细粒度的授权控制。从REST的角度来看,策略将应用于资源级别。例如:"POST:/user/123"只授权给A用户。
我已经与客户进行了调查,85%的人只会使用ACL的“允许”策略,默认情况下ACL控制将拒绝所有内容。所以好吧,现在我有所有开发此控件所需的信息。但我不知道最佳实现方式。
我的第一个想法是:
我喜欢这个设计,因为其他API不需要知道授权/身份验证服务。而且它非常非常快,因为它使用内存缓存策略,而不是每次收到新请求时都向Elasticsearch发出请求来测试授权。
但现在我需要实现ACL以提供更细粒度的授权控制。从REST的角度来看,策略将应用于资源级别。例如:"POST:/user/123"只授权给A用户。
我已经与客户进行了调查,85%的人只会使用ACL的“允许”策略,默认情况下ACL控制将拒绝所有内容。所以好吧,现在我有所有开发此控件所需的信息。但我不知道最佳实现方式。
我的第一个想法是:
- 系统最重要的质量是可扩展性;
- 好吧,无法在内存中缓存,我已经模拟了10万个用户和100万个资源(可能是真实场景),内存量非常大,如果进行缓存,这个功能将具有高成本;
- 在这种情况下,认证服务无法处理ACL,因为它无法过滤搜索。身份验证服务不会拦截结果,只会验证标头和路由与角色是否匹配;
- 所以,根据所有这些要点,如果在Elasticsearch的每个文档中都有一个名为“acl_allow_method_user”的新字段,该字段是一个方法+用户ID授权使用此资源的数组,会怎样呢?将最终得到像这样的东西:
"acl_allow_method_user":["POST:123434"]
- 有任何ACL经验的人,这是一个好的设计吗?
- Elasticsearch对数组字段的大小有限制吗?
- 性能如何?这种方法会有影响吗?