🚦 RBAC service for Skygear

NOTE: This service uses casbin as db name, all records e.g. policy, group are under casbin_rule table

Development

Requirements

Docker
Go 1.12

Get started

make setup-dev
# We use docker for our database for development
docker-compose up
# Run app
DATABASE_URL=postgresql://postgres:@localhost:5432/postgres?sslmode=disable go run main.go
# or
make run-dev

Testing

make test

Docker

docker pull oursky/skygear-rbac

docker run -e "DATABASE_URL=abc" oursky/skygear-rbac:latest

Current model

(
  (g(r.domain, p.domain) || g('root', r.sub)) && # request domain is SAME as policy domain (to disable inheritance of access rights)
  (
    (g2(r.sub, p.sub, r.domain) || (r.sub == p.sub && r.domain == p.domain)) || # request subject is assigned role/is the role in domain
    (g2(r.sub, p.sub, 'root') || (r.sub == p.sub && r.domain == 'root')) # request subject is assigned role/is the role in root
  )
) &&
(r.obj == p.obj || p.obj == '.*') &&  # request object matches policy
(r.act == p.act || p.act == '.*') && # request action matches policy
!g4(r.sub, 'disabled') && # subject in request is not disabled / archived
!g4(p.sub, 'disabled') # subject in policy is not disabled / archived

Rewrite RBAC without Casbin?

Background

Initially we chose casbin because it provides the most flexibility in terms of authorization model.

Why Casbin might not be best solution

Confusing model

After using in project, the dynamic model syntax especially policy_matcher is actually confusing.

We might argue that the dynamic model is useful for projects that are at prototype stage. The problem is this library does not offer any way to migrate according to model changes. For example you cannot add another column in policy.

Bad performance

If we put the model aside, Casbin is no different from simply querying for object + subject + action (+ domain) and then return effect.

Policy matcher makes it impossible to perform pagination or filtering, since the matcher itself will be parsed into golang code and executed on each record.

The only thing people need to customize is inheritance, which seems better resolved by adding a table.

Also searching for all roles is not done with recursive query since they need to consider compatitablity among non-db adaptors.

Cannot be used in listing

It is fine to get each record, run enforce request on it. This however is not performant to apply on record listing.

One possible way to have per-record access control would be:

User has a table which needs access control e.g. file
User adds a JSON column 'access'

{
  "view": ["user_id1", "role_id1", "role_id2"]
}

User provides a webhook for RBAC to update permissions
When list the table, list of roles associated to user is fetched and user write their own query to match if the ids overlap with 'access'

oursky / skygear-rbac Goto Github PK

skygear-rbac's Introduction

🚦 RBAC service for Skygear

Development

Requirements

Get started

Testing

Docker

Current model

skygear-rbac's People

Contributors

Watchers

Forkers

skygear-rbac's Issues

Background

Why Casbin might not be best solution

Confusing model

Bad performance

Cannot be used in listing

Tasks

Recommend Projects

Recommend Topics

Recommend Org