Blame
|
1 | # Permissions |
||||||
| 2 | ||||||||
|
3 | Permissions define what an authenticated user, service, team, or integration is allowed to do inside AeThex. |
||||||
|
4 | |||||||
|
5 | <div class="docs-section-heading"> |
||||||
| 6 | <h2>Authorization layer</h2> |
|||||||
| 7 | <p>Authentication answers who someone is. Permissions answer what they can access.</p> |
|||||||
| 8 | </div> |
|||||||
|
9 | |||||||
|
10 | Permissions should be evaluated after [[Authentication]] and inside the relevant [[Organizations]], [[Teams]], or [[Projects]] context. A user may have different access depending on which organization or project they are acting within. |
||||||
| 11 | ||||||||
| 12 | ## Permission concepts |
|||||||
| 13 | ||||||||
| 14 | - Roles: named sets of access rules. |
|||||||
| 15 | - Scopes: API-level capabilities granted to tokens or integrations. |
|||||||
| 16 | - Ownership: direct control over a resource. |
|||||||
| 17 | - Team membership: inherited access through [[Teams]]. |
|||||||
| 18 | - Administrative override: powerful access that should be logged and limited. |
|||||||
| 19 | ||||||||
| 20 | ## Safe defaults |
|||||||
| 21 | ||||||||
| 22 | 1. Deny by default. |
|||||||
| 23 | 2. Grant the smallest useful role. |
|||||||
| 24 | 3. Separate read, write, admin, and billing/security privileges. |
|||||||
| 25 | 4. Audit sensitive permission changes. |
|||||||
| 26 | 5. Revoke access when users leave teams or organizations. |
|||||||
| 27 | ||||||||
| 28 | <div class="docs-grid"> |
|||||||
| 29 | <a class="docs-card" href="/Authentication">Authentication</a> |
|||||||
| 30 | <a class="docs-card" href="/Teams">Teams</a> |
|||||||
| 31 | <a class="docs-card" href="/Security-Model">Security Model</a> |
|||||||
| 32 | <a class="docs-card" href="/Policies">Policies</a> |
|||||||
| 33 | </div> |
|||||||