paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 38 Packages Projects Releases Wiki Activity

remove lengthy definitions

Browse Source 
Signed-off-by: Aramis <sennyeyaramis@gmail.com>
This commit is contained in:
Aramis
2024-01-30 22:43:23 -05:00
parent f0192acb70
commit ddfeada980
2 changed files with 14 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/permissions/concepts.md
+8
View File
@@ -4,6 +4,14 @@ title: Concepts
description: A list of important permission framework concepts
---
### Permission
Any action that a user performs within Backstage may be represented as a permission. More complex actions, like executing a [software template](../references/glossary.md#software-templates), may require [authorization](../references/glossary.md#authorization) for multiple permissions throughout the flow. Permissions are identified by a unique name and optionally include a set of attributes that describe the corresponding action. [Plugins](../references/glossary.md#plugin) are responsible for defining and exposing the permissions they enforce as well as enforcing restrictions from the permission framework.
### Policy
User [permissions](../references/glossary.md#permission-permission-plugin) are authorized by a central, user-defined permission policy. At a high level, a policy is a function that receives a Backstage user and permission, and returns a decision to allow or deny. Policies are expressed as code, which decouples the framework from any particular [authorization](../references/glossary.md#authorization) model, like role-based access control (RBAC) or attribute-based access control (ABAC).
### Policy decision versus enforcement
Two important responsibilities of any authorization system are to decide if a user can do something, and to enforce that decision. In the Backstage permission framework, policies are responsible for decisions and plugins (typically backends) are responsible for enforcing them.