GRBAC
项目地址: https://github.com/storyicon/grbac
Grbac是一个快速,优雅和简洁的RBAC框架。它支持增强的通配符并使用Radix树匹配HTTP请求。令人惊奇的是,您可以在任何现有的数据库和数据结构中轻松使用它。
grbac的作用是确保指定的资源只能由指定的角色访问。请注意,grbac不负责存储鉴权规则和分辨“当前请求发起者具有哪些角色”,更不负责角色的创建、分配等。这意味着您应该首先配置规则信息,并提供每个请求的发起者具有的角色。
grbac将Host
、Path
和Method
的组合视为Resource
,并将Resource
绑定到一组角色规则(称为Permission
)。只有符合这些规则的用户才能访问相应的Resource
。
读取鉴权规则的组件称为Loader
。grbac预置了一些Loader
,你也可以通过实现func()(grbac.Rules,error)
来根据你的设计来自定义Loader
,并通过grbac.WithLoader
加载它。
1. 最常见的用例
下面是最常见的用例,它使用gin
,并将grbac
包装成了一个中间件。通过这个例子,你可以很容易地知道如何在其他http框架中使用grbac
(比如echo
,iris
,ace
等):
package main
import (
"github.com/gin-gonic/gin"
"github.com/storyicon/grbac"
"net/http"
"time"
)
func LoadAuthorizationRules() (rules grbac.Rules, err error) {
// 在这里实现你的逻辑
// ...
// 你可以从数据库或文件加载授权规则
// 但是你需要以 grbac.Rules 的格式返回你的身份验证规则
// 提示:你还可以将此函数绑定到golang结构体
return
}
func QueryRolesByHeaders(header http.Header) (roles []string,err error){
// 在这里实现你的逻辑
// ...
// 这个逻辑可能是从请求的Headers中获取token,并且根据token从数据库中查询用户的相应角色。
return roles, err
}
func Authorization() gin.HandlerFunc {
// 在这里,我们通过“grbac.WithLoader”接口使用自定义Loader功能
// 并指定应每分钟调用一次LoadAuthorizationRules函数以获取最新的身份验证规则。
// Grbac还提供一些现成的Loader:
// grbac.WithYAML
// grbac.WithRules
// grbac.WithJSON
// ...
rbac, err := grbac.New(grbac.WithLoader(LoadAuthorizationRules, time.Minute))
if err != nil {
panic(err)
}
return func(c *gin.Context) {
roles, err := QueryRolesByHeaders(c.Request.Header)
if err != nil {
c.AbortWithError(http.StatusInternalServerError, err)
return
}
state, _ := rbac.IsRequestGranted(c.Request, roles)
if !state.IsGranted() {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
}
}
func main(){
c := gin.New()
c.Use(Authorization())
// 在这里通过c.Get、c.Post等函数绑定你的API
// ...
c.Run(":8080")
}
2. 概念
这里有一些关于grbac
的概念。这很简单,你可能只需要三分钟就能理解。
2.1. Rule
// Rule即规则,用于定义Resource和Permission之间的关系
type Rule struct {
// ID决定了Rule的优先级。
// ID值越大意味着Rule的优先级越高。
// 当请求被多个规则同时匹配时,grbac将仅使用具有最高ID值的规则。
// 如果有多个规则同时具有最大的ID,则将随机使用其中一个规则。
ID int `json:"id"`
*Resource
*Permission
}
如你所见,Rule
由三部分组成:ID
,Resource
和Permission
。
“ID”确定规则的优先级。
当请求同时满足多个规则时(例如在通配符中),
grbac
将选择具有最高ID的那个,然后使用其权限定义进行身份验证。
如果有多个规则同时具有最大的ID,则将随机使用其中一个规则(所以请避免这种情况)。
下面有一个非常简单的例子:
#Rule
- id: 0
# Resource
host: "*"
path: "**"
method: "*"
# Permission
authorized_roles:
- "*"
forbidden_roles: []
allow_anyone: false
#Rule
- id: 1
# Resource
host: domain.com
path: "/article"
method: "{DELETE,POST,PUT}"
# Permission
authorized_roles:
- editor
forbidden_roles: []
allow_anyone: false
在以yaml格式编写的此配置文件中,ID=0 的规则表明任何具有任何角色的人都可以访问所有资源。
但是ID=1的规则表明只有editor
可以对文章进行增删改操作。
这样,除了文章的操作只能由editor
访问之外,任何具有任何角色的人都可以访问所有其他资源。
2.2. Resource
type Resource struct {
// Host 定义资源的Host,允许使用增强的通配符。
Host string `json:"host"`
// Path 定义资源的Path,允许使用增强的通配符。
Path string `json:"path"`
// Method 定义资源的Method,允许使用增