Seonglae Chorelation db with typing
implementation on every api
어디로 가는지 user 권한 수정하면
relation db sync with workos and auto creation
assignment ui for each resource type
- settings/users - tenant admin, group
- settings/connection - connection manager
- asset/users
- artifact/users
Cherry pick
- trpc wrapper 7a01d33a7c39c44641fdf998e66a30d8363a4684
- authz engine 7664035fe2e19a972cf120467b474b54ddc83ed7
- 3078e94b90d0d031a001370e100c1040ad42a372
- authz scripts 8a5068c7b2b9dccc09f77d3edc1ceb14601dcd5e
Authz migration
automatic assignment code when creating or connecting
existing relations to relations table with a single scripts run
before that we need to clarify the policy
if someone create a tasks on asset, does every editor of the asset become an editor?
or only creator for the task can edit the task
does the all viewer of the asset can see the tasks or editors only can see the tasks
which relations generated automatically, while some relations are assigned
are we gonna use joint table information for these or save duplicated information in the relation
- asset
- artifact
- task
- connection
- settting (tenant)
What i want to do is Cedar
- Github
- Sharepoint
- Azure
Connection
Local export experiment
artifact export
- 12500 - 11s, 6MB
- 25000 - 18s, 4.5MB
- 37500 - 26s, 3MB
- 50000 - 33s, 1.5MB
asset export
- 1100 - 8s, 151KB
- 2200 - 14s, 305KB
- 3300 - 20s, 471KB
- 4400 - 27s, 632KB
Files
workosSync.ts
workos-jwt-authorizer.ts
permission/index.ts
Playground
Fetch and AuthZ check
- 6137 artifacts in 28798ms, 4272 allowed (25 pages)
- 5187ms 10 batch
- 4683ms 20 batch
- 3190ms 25 batch
AuthZ listing and Fetch
- Fetched 4272 artifacts in 8335ms (43 page)
Business logic is single
resource level is currently 3 levels.
Globally, INVENTORY, where we could make a connection for resource fetching from the request of admin users. After connection created, we aggregate resources from the connection contained in to create artifacts for each resource. This ARTIFACT is the most granual layer that we are treat.
를 생성하는데 그게 가장 아래 단계 우리는 resource 원래 contributor 랑 creator 한테 artifact access 권한을 주려고 해 근데 우리는 보통 여러 task 를 artifact 를 추상화한 asset 이라는 단계에서 다뤄. 그 clustering된 asset이 ai 인지 아닌 판단도 하고 bias testing 이나 agent graph generation 등 여러 task 를 실행하기도 해 여러 권한들이 잇겠지 share라거나 이거를 UAM으로 구현하려는 곳은 ai governance platform 이야 그래서 asset 을 관리하는 게 ai govence team 에게 보통 권한이 부여된다고 다만 asset 을 이 artifact creator 나 contributor 가 볼수있을지 없을지는 미정이야 좀 flexible 해야해 3단계 내에서도 근데 이걸 user asset joint table 은 있는데 user 간 그룹할 group table 이 필요할지는 모르겟다. group 간ㄴ table 내에서 paraent group 이런 column 이 좋은 디자인인지도 헷갈리고 또 고려할건 user 가 group 에 assign 된다 치자 그러면 ai governance team group 이 네트워크에 존재해야되는건지 contributor는 developer team group 에 assign 될텐데 network edge 가 없어서 같은 resource 접근이 안되잖아. 그리고 artifact 나 asset 의 owner 가 rebac 을 따른다면 어떤 user 나 group 에 할당되어야할지도 지금 좀 애매해 parent group 을 만들어야하나? 아니면 group 자체가 rebac 에 안맞는 개념인가 이런거도 treat 되야 모던 architecture 이긴 할텐데 너 의견은 어때
일단 level 은 3단계야 inventory 에서 여러 외부 resource connection 생성하는 admin 그리고 connection 생성되면 connection 포함된 resouce 별 artifact 를 생성하는데 그게 가장 아래 단계 우리는 resource 원래 contributor 랑 creator 한테 artifact access 권한을 주려고 해 근데 우리는 보통 여러 task 를 artifact 를 추상화한 asset 이라는 단계에서 다뤄. 그 clustering된 asset이 ai 인지 아닌 판단도 하고 bias testing 이나 agent graph generation 등 여러 task 를 실행하기도 해 여러 권한들이 잇겠지 share라거나 이거를 UAM으로 구현하려는 곳은 ai governance platform 이야 그래서 asset 을 관리하는 게 ai govence team 에게 보통 권한이 부여된다고 다만 asset 을 이 artifact creator 나 contributor 가 볼수있을지 없을지는 미정이야 좀 flexible 해야해 3단계 내에서도 근데 이걸 user asset joint table 은 있는데 user 간 그룹할 group table 이 필요할지는 모르겟다. group 간ㄴ table 내에서 paraent group 이런 column 이 좋은 디자인인지도 헷갈리고 또 고려할건 user 가 group 에 assign 된다 치자 그러면 ai governance team group 이 네트워크에 존재해야되는건지 contributor는 developer team group 에 assign 될텐데 network edge 가 없어서 같은 resource 접근이 안되잖아. 그리고 artifact 나 asset 의 owner 가 rebac 을 따른다면 어떤 user 나 group 에 할당되어야할지도 지금 좀 애매해 parent group 을 만들어야하나? 아니면 group 자체가 rebac 에 안맞
Cherry Pick SHA
ac28f737c91806c2fb52c9753230ca88f629a979draft schema of the workos
279b9cd1c67b24b615c623c276e803308309136ctrpc router of fga before fetchingquery()
1100f40b4614356fb3981e40b1848a140b313f50filter after fetching bycheckBatch()
b02eec584114b25194fa8920447d0aadba395eebpackages/scripts to sync workos warrenties
WorkOS FGA
6137 artifacts globally, 4272 artifacts accessible
AuthZ listing and Fetch
- Fetched 4272 artifacts in 8335ms (43 page)
Fetch and AuthZ check
- 6137 artifacts in 28798ms, 4272 allowed (25 pages)
- 5187ms 10 parallel batch
- 4683ms 20 parallel batch
- 3190ms 25 parallel batch
if 6137 artifacts globally, 4 artifacts accessible
Average time full
8-10 seconds
Cedar
given all relation
given related relations
Average time full
- 6000 → 3000 artifacts 9-10 seconds
- after optimizatio 7s
Check time
- 6000 → 3000 1000ms
Options
0. WorkOS FGA
-slow
-sunset in near future
1. OpenFGA
+configurable performance
-self-hosting overhead
+Postgres installation
2. Cedar
+Fast
-Require Rust dependency
-Only 1-hop relation (Our Business logic is single but prevent future flexibility)
3. SpiceDB
+Fast (hybrid traverse)
+ReBAC traverse
-self-hosting overhead
+Postgres schema installing
-self hosted
Relation Type
Artifact
- viewer - manual assignment
- editor - manual assignment
- contributor - email aggregation
- cascading
Asset
- viewer - manual assignment
- editor - manual assignment
- owner - group? or user
- cascading
Task
- viewer - manual assignment
- editor - manual assignment
- reviewer - manual assignment
- cascading
Eval
- runner - manual assign
- jment
- cascading
(Workflow)
- view
- edit
(Framework)
- create
- view
()
Schema
- admin
Connection
- manager - manual assignment (workos permission)
Tenant (setting)
- admin - workos configuration
minimal/maximal set of authority
Group?
- nested group
- group is 1st class citizen? (same as user) or just grouped managing with limited relation
Potential relation
- share
- delegate
- …
in
PR order
- relation table with relation script
- remove asst-user joint table?
- user context provider and trpc
- artifact / asset core function
- other core functions
- add groups feature
- directory sync azure for group