微服务中的授权-如何使用ACL进行域对象或实体级别的访问控制? [英] Authorisation in microservices - how to approach domain object or entity level access control using ACL?

问题描述

我目前正在Java Spring Cloud上构建基于微服务的系统.一些微服务使用PostgreSQL，其中一些使用MongoDB. REST和JMS用于通信.计划是使用SSO和OAuth2进行身份验证

I am currently building microservices based system on java Spring Cloud. Some microservices use PostgreSQL and some of them MongoDB. REST and JMS is used for communication. The plan is to use SSO and OAuth2 for authentication

我面临的挑战是必须在域对象/实体级别上进行授权.这意味着需要某种ACL(访问控制列表).这种架构的最佳实践是避免类似的事情，并且可能在每个微服务的应用程序/服务层级别上具有粗糙的安全性，但是不幸的是，这是不可能的.

The challenge I am facing is that authorisation have to be done on domain object/entity level. It means some kind of ACL (Access Control List) is needed. The best practice for this kind of architecture is to avoid something like this and have coarse grained security probably on application/service layer level in every microservice but unfortunately it is not possible.

我的最终想法是使用Spring Security ACL，并将ACL表放在所有微服务之间的共享数据库中.该数据库只能由Spring基础结构或通过Spring api访问.数据库模式看起来很稳定，不太可能改变.在这种情况下，我只会违反有关在微服务之间共享db的规则.

My final idea is to use Spring Security ACL and have the ACL tables in shared database between all microservices. The database would be accessed only by Spring infrastructure or through Spring api. The DB schema looks stable and unlikely will change. In this case I would simply break the rule about sharing db between microservices.

我正在考虑使用各种分布式解决方案，但留给了他们:

I was considering different kinds of distributed solutions but left them:

• 一个具有ACL的微服务，并使用rest访问它-问题是太多的http调用和性能下降.我必须扩展Spring Security ACL才能用rest调用代替数据库访问
每个微服务中针对其自身实体的
• ACL-听起来很合理，但可以想象一个案例，其中包含一些读取模型的实体，这些实体与其他微服务或存在于不同范围上下文(不同微服务)中的同一实体同步. ACL可能真的变得难以管理，并且可能成为错误的根源.
• 具有ACL表的一个微服务，该ACL表作为读取模型与其他微服务同步.问题在于，Spring Security ACL中没有针对MongoDB的支持.我在github上看到了一些自定义解决方案，是的，它是可行的.但是...创建新实体时，我必须在拥有ACL的微服务中创建记录，然后将其作为读取模型异步同步到拥有该实体的微服务.听起来不是一个简单的解决方案
• 在API网关上选择一些基于URL的访问控制.但是我将不得不以某种方式修改Spring Security ACL. API网关必须对其他服务了解太多.访问控制的粒度与REST api粒度绑定在一起.也许我无法想象这种方法会带来的所有后果和其他问题
• 最后，我提到的共享数据库解决方案是我的最爱.实际上，这是我被取消资格的第一个数据库，因为它是共享"数据库.但是在经历了各种可能性之后，在我看来这是唯一可行的方法.万一我需要使用某种类型的缓存(因为需要分布式缓存)，还会带来更多的复杂性.

• One microservice with ACL and accessing it using rest - The problem is too many http calls and performance degradation. I would have to extend Spring Security ACL to replace db access by rest calls
• ACL in every microservice for its own entities - Sounds quite reasonable but imagine a case having some read models of entities synchronised to some other microservices or same entity that exists in different bounded contexts (different microservices). ACLs can become really unmanageable and can be source of errors.
• One microservice with ACL tables that are synchronised to other microservices as a read model. The problem is that there is no support in Spring Security ACL for MongoDB. I have seen some custom solutions on github and yes it is doable. But...when creating a new entity I have to create record in the microservice that owns ACL and then it is asynchronously synchronised as a read model to microservice owning the entity. It does not sound as a easy solution
• Choose some URL based access control on API gateway. But I would have to modify Spring Security ACL somehow. The API gateway would have to know too much about other services. Granularity of access control is bound to REST api granularity. Maybe I can not imagine all the consequences and other problems that would this approach bring
• Finally the solution with shared db that I mentioned is my favorite. Actually it was the first one I have disqualified because it is "shared" database. But after going through possibilities it seemed to me that this is the only one that would work. There is some more additional complexity in case I would like to use some kind of caching because distributed cache would be needed.

我真的会使用一些建议和意见来处理体系结构，因为这确实很棘手，并且很多事情在这里可能会出错.

I would really use some advice and opinions how to approach the architecture because this is really tricky and a lot of things can go wrong here.

非常感谢，

卢卡斯

推荐答案

我对您的授权要求没有完整而清晰的描述. 我假设经过身份验证的用户与域对象/实体权限之间存在关联.

I don't have a full and clear picture of your authorization requirements. I'm assuming a correlation between authenticated users and domain object/entity permissions.

要考虑的一个选项是定义与您的域对象/实体权限相对应的用户属性，并实施基于属性的访问控制(ABAC)策略.

One option to consider is to define user attributes corresponding to your domain object/entity permissions, and implement an Attribute-based Access Control (ABAC) policy.

这些属性与用户身份绑定在一起并与之一起存储在您的存储库中，并在执行身份验证时进行检索.

The attributes are tied to and stored with the users identity in your repository, and retrieved when performing your authentication.

这篇关于微服务中的授权-如何使用ACL进行域对象或实体级别的访问控制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！