Open hhstore opened 5 years ago
A--> Access Control Server --> B
A (SDK) --> B
, A侧, SDK包, 计算访问权限, 直接到B. P2P
架构, 点到点方案. 把计算量放在请求侧. 不会产生性能瓶颈C/S
架构, 容易在server处出现单点故障, 容易背锅. 而且出故障的概率极高. 故障对业务整体影响太大.iam open source solution github
特点
Casbin 做了什么:
支持自定义请求的格式,默认的请求格式为{subject, object, action}。
具有访问控制模型model和策略policy两个核心概念。
支持RBAC中的多层角色继承,不止主体可以有角色,资源也可以具有角色。
支持超级用户,如 root 或 Administrator,超级用户可以不受授权策略的约束访问任意资源。
支持多种内置的操作符,如 keyMatch,方便对路径式的资源进行管理,如 /foo/bar 可以映射到 /foo*
Casbin 不做的事情:
身份认证 authentication(即验证用户的用户名、密码),casbin只负责访问控制。应该有其他专门的组件负责身份认证,然后由casbin进行访问控制,二者是相互配合的关系。
管理用户列表或角色列表。 Casbin 认为由项目自身来管理用户、角色列表更为合适, 用户通常有他们的密码,但是 Casbin 的设计思想并不是把它作为一个存储密码的容器。 而是存储RBAC方案中用户和角色之间的映射关系。
与 oauth2 结合: https://github.com/casbin/casbin/issues/52
自定义规则匹配示例: https://github.com/casbin/casbin/blob/master/examples/keymatch_custom_model.conf
model语法规则: https://casbin.org/docs/zh-CN/syntax-for-models
rest规则示例: https://github.com/casbin/casbin/blob/master/examples/keymatch2_policy.csv
rest规则示例2: https://github.com/casbin/casbin/blob/master/examples/keymatch_policy.csv
有几个注意事项:
1. Casbin 只存储用户角色的映射关系。
2. Cabin 没有验证用户是否是有效的用户,或者角色是一个有效的角色。 这应该通过认证来解决。
3. RBAC 系统中的用户名称和角色名称不应相同。因为Casbin将用户名和角色识别为字符串, 所以当前语境下Casbin无法得出这个字面量到底指代用户 alice 还是角色 alice。 这时,使用明确的 role_alice ,问题便可迎刃而解。
4. 假设A具有角色 B,B 具有角色 C,并且 A 有角色 C。 这种传递性在当前版本会造成死循环。
# 服务端:
go get github.com/casbin/casbin-server
cd casbin-server/
# gen grpc:
protoc -I proto --go_out=plugins=grpc:proto proto/casbin.proto
# 启动:
go run main.go
# 客户端:
go get github.com/casbin/casbin-go-client
cd casbin-go-client/
# 启动客户端:
go run main.go
related:
381
139 : Authorization 方案
138 : 开发者中心方案