From 0fc4d08a6e571c869b87e6fe09933b8df1c7ab57 Mon Sep 17 00:00:00 2001 From: S A G A R <110724849+tmsagarofficial@users.noreply.github.com> Date: Mon, 7 Oct 2024 19:42:02 +0530 Subject: [PATCH] Tmsagarofficial patch 1 (#42) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update README.md * Update README.md * Update README.md * Update README.md * Update stores/abac-with-rebac/README.md Co-authored-by: Andrés Aguiar --------- Co-authored-by: Andrés Aguiar Co-authored-by: Andrés Aguiar --- stores/abac-with-rebac/README.md | 6 ++--- stores/advanced-entitlements/README.md | 6 ++--- stores/github/README.md | 32 +++++++++++++------------- stores/slack/README.md | 20 ++++++++-------- 4 files changed, 32 insertions(+), 32 deletions(-) diff --git a/stores/abac-with-rebac/README.md b/stores/abac-with-rebac/README.md index 1e476d6..26bf01d 100644 --- a/stores/abac-with-rebac/README.md +++ b/stores/abac-with-rebac/README.md @@ -1,8 +1,8 @@ -# OpenFGA Modeling Attribute-Based Access Control with Relationship Based Access Control +# OpenFGA Modeling Attribute-Based Access Control with Relationship-Based Access Control ## Use-Case -This example demonstrates how to model Attribute-Based access control scenarios purely with Relationship Based Access Control constructs. +This example demonstrates how to model Attribute-Based access control scenarios with relationship-based access Control constructs. In ABAC, you make authorization decisions based on different attributes of the user, the resource, and the environment. Depending on the kind of attribute, you can model them pretty easily in ReBAC or not. @@ -51,7 +51,7 @@ type document define can_view : viewer from published ``` -If the attribute is a discrete variable with many possible values, e.g. birth date, age, IP address, a a currency amount, then it's not possible to be modeled with pure ReBAC and you need to resort to using [OpenFGA conditions](https://openfga.dev/docs/modeling/conditions). +If the attribute is a discrete variable with many possible values, e.g. birth date, age, IP address, a currency amount, then it's not possible to be modeled with pure ReBAC and you need to resort to using [OpenFGA conditions](https://openfga.dev/docs/modeling/conditions). If you can model your attribute as a relation, you should do so, as it will make your model simpler and more efficient. diff --git a/stores/advanced-entitlements/README.md b/stores/advanced-entitlements/README.md index 9df4c96..5589283 100644 --- a/stores/advanced-entitlements/README.md +++ b/stores/advanced-entitlements/README.md @@ -2,11 +2,11 @@ ## Use-Case -This entitlements model is inspired on [Notion's subscription plans](https://www.notion.so/pricing). +This entitlements model is inspired by [Notion's subscription plans](https://www.notion.so/pricing). -Entitlements limits can be defined based on feature usage like number of collaborators, rows synced, page history days. +Entitlement limits can be defined based on feature usage like number of collaborators, rows synced, and page history days. -The model, tuples and unit tests are detailed in [store.fga.yaml](./store.fga.yaml). +The model, tuples, and unit tests are detailed in [store.fga.yaml](./store.fga.yaml). ## Try It Out diff --git a/stores/github/README.md b/stores/github/README.md index b93e63c..e5223d1 100644 --- a/stores/github/README.md +++ b/stores/github/README.md @@ -27,26 +27,26 @@ This model is based on GitHub's permission model according to their [documentati ### Scenario -There are users, organizations, teams and repositories +There are users, organizations, teams, and repositories -- There are five users: Anne, Beth, Charles, Diane and Erik +- There are five users: Anne, Beth, Charles, Diane, and Erik - There is an OpenFGA organization that owns the openfga/openfga repository -- There is an openfga/core team and a openfga/backend team +- There is an openfga/core team and an openfga/backend team - Members of the openfga/backend team are members of the openfga/core team - Members of the openfga/core team are admins of the openfga/openfga repository - Erik is a member of the OpenFGA organization - Diane is a member of the openfga/backend team - Charles is a member of the openfga/core team -- Anne is a reader on the openfga/openfga repository +- Anne is a reader of the openfga/openfga repository - Beth is a writer on the openfga/openfga repository - The OpenFGA organization has been configured with the "repository admin" base permission, which means all the organization members have the admin role on all the repositories the organization owns ### Expected Outcomes -- Anne is a reader on the openfga/openfga repository +- Anne is a reader of the openfga/openfga repository - Anne **is not** a triager on the openfga/openfga repository - Diane is an admin on the openfga/openfga repository -- Erik is a reader on the openfga/openfga repository +- Erik is a reader of the openfga/openfga repository - Charles is a writer on the openfga/openfga repository - Beth **is not** an admin on the openfga/openfga repository @@ -62,38 +62,38 @@ model # There are users type user -# there are organizations +# There are organizations type organization relations # Organizations can have users who own them define owner: [user] # Organizations can have members (any owner of the organization is automatically a member) define member: [user] or owner - # Organizations has a set of base permissions, such as repository admin, writer and reader + # Organizations have a set of base permissions, such as repository admin, writer, and reader define repo_admin: [user, organization#member] define repo_reader: [user, organization#member] define repo_writer: [user, organization#member] -# there are teams +# There are teams type team relations # teams have members define member: [user, team#member] -# there are repositories +# There are repositories type repo relations - # repositories have organizations who own them + # Repositories have organizations that own them define owner: [organization] - # repository have admins, they can be assigned or inherited (anyone who has the repository admin role on the owner organization is an owner on the repo) + # Repositories have admins, they can be assigned or inherited (anyone who has the repository admin role on the owner organization is an owner on the repo) define admin: [user, team#member] or repo_admin from owner - # maintainers on a repo are anyone who is directly assigned or anyone who is an owner on the repo + # Maintainers on a repo are anyone who is directly assigned or anyone who is an owner of the repo define maintainer: [user, team#member] or admin - # repo writers are users who are directly assigned, anyone who is a maintainer or anyone who has the repository writer role on the owner organization + # Repo writers are users who are directly assigned, anyone who is a maintainer, or anyone who has the repository writer role on the owner organization define writer: [user, team#member] or maintainer or repo_writer from owner - # triagers on a repo are anyone who is directly assigned or anyone who is a writer on the repo + # Triagers on a repo are anyone who is directly assigned or anyone who is a writer on the repo define triager: [user, team#member] or writer - # repo readers are users who are directly assigned, anyone who is a triager or anyone who has the repository reader role on the owner organization + # Repo readers are users who are directly assigned, anyone who is a triager or anyone who has the repository reader role on the owner organization define reader: [user, team#member] or triager or repo_reader from owner ``` diff --git a/stores/slack/README.md b/stores/slack/README.md index 9854a22..47b0f4b 100644 --- a/stores/slack/README.md +++ b/stores/slack/README.md @@ -19,7 +19,7 @@ This model is inspired by Slack and some of their publicly documented roles and permissions. -> As reference, Slack's publicly available docs were used: +> As a reference, Slack's publicly available docs were used: > > - [Role Management at Slack](https://slack.engineering/role-management-at-slack/) > - [Types of Roles in Slack](https://slack.com/intl/en-ca/help/articles/360018112273-Types-of-roles-in-Slack) @@ -36,7 +36,7 @@ Workspace Roles: System Roles: -- **Channels Admin**: This type of user has the permission to archive channels, rename channels, create private channels, and convert public channels into private channels. +- **Channels Admin**: This type of user has permission to archive channels, rename channels, create private channels, and convert public channels into private channels. Channel Settings: @@ -57,7 +57,7 @@ There are users, workspaces and channels. - #general channel is a public channel, anyone who is a member of the Sandcastle workspace can view it - In the Sandcastle workspace: - Amy has a legacy admin role - - Bob has a channels admin role + - Bob has a channel admin role - Catherine and Emily are members - David is a guest - Catherine and Emily are normal members of the Sandcastle workspace, they can view all public channels, as well as channels they have been invited to @@ -89,23 +89,23 @@ type user # There are workspaces type workspace relations - # users can have the legacy admin role on workspaces + # Users can have the legacy admin role on workspaces define legacy_admin: [user] - # users can have the new channels admin role on workspaces (anyone with a legacy admin role also gets all the channels admin role access) + # Users can have the new channels admin role on workspaces (anyone with a legacy admin role also gets all the channels admin role access) define channels_admin: [user] or legacy_admin - # users can have the member role on workspaces, admins automatically get all access granted to members + # Users can have the member role on workspaces, admins automatically get all access granted to members define member: [user] or legacy_admin or channels_admin - # users can have the guest role on workspaces + # Users can have the guest role on workspaces define guest: [user] # There are channels type channel relations - # channels have a parent workspace + # Channels have a parent workspace define parent_workspace: [workspace] - # users can be writers on channels + # Users can be writers on channels define writer: [user,workspace#member] - # users can be viewers on channels, writers inherit any access viewers have + # Users can be viewers on channels, writers inherit any access viewers have define commenter: [user,workspace#member] or writer ```