|
2 | 2 |
|
3 | 3 | !!! note "Single-note Chroma"
|
4 | 4 |
|
5 |
| - The below strategies are applicable to single-node Chroma only. |
| 5 | + The below strategies are applicable to single-node Chroma only. The strategies require your app to act as both PEP (Policy Enforcement Point) |
| 6 | + and PDP (Policy Decision Point) for authorization. |
| 7 | + |
| 8 | +!!! warn "Authorization" |
| 9 | + |
| 10 | + We are in the process of creating a list of articles on how to implement proper authorization in Chroma, |
| 11 | + leveraging the an external service and Chroma's auth plugins. The first article of the series is available in |
| 12 | + [Medium](https://medium.com/@amikostech/implementing-multi-tenancy-in-chroma-part-1-multi-user-basic-auth-a4e790f1254d) |
| 13 | + and will also be made available here soon. |
6 | 14 |
|
7 | 15 | ## Introduction
|
8 | 16 |
|
9 | 17 | There are several multi-tenancy strategies available to users of Chroma. The actual strategy will depend on the needs of
|
10 | 18 | the user and the application. The strategies below apply to multi-user environments, but do no factor in partly-shared
|
11 | 19 | resources like groups or teams.
|
12 | 20 |
|
13 |
| -- **Doc-Per-User**: In this scenario, the app maintains multiple collections and each collection document is associated |
| 21 | +- **User-Per-Doc**: In this scenario, the app maintains multiple collections and each collection document is associated |
14 | 22 | with a single user.
|
15 |
| -- **Doc-Per-Collection**: In this scenario, the app maintains multiple collections and each collection is |
| 23 | +- **User-Per-Collection**: In this scenario, the app maintains multiple collections and each collection is |
16 | 24 | associated with a single user.
|
17 |
| -- **Doc-Per-Database**: In this scenario, the app maintains multiple databases with a single tenant and each database is |
| 25 | +- **User-Per-Database**: In this scenario, the app maintains multiple databases with a single tenant and each database |
| 26 | + is |
18 | 27 | associated with a single user.
|
19 |
| -- **Doc-Per-Tenant**: In this scenario, the app maintains multiple tenants and each tenant is associated with a single |
| 28 | +- **User-Per-Tenant**: In this scenario, the app maintains multiple tenants and each tenant is associated with a single |
20 | 29 | user.
|
21 | 30 |
|
22 |
| -## Doc-Per-User |
| 31 | +## User-Per-Doc |
| 32 | + |
| 33 | +The goal of this strategy is to grant user permissions to access individual documents. |
23 | 34 |
|
24 | 35 | 
|
25 | 36 |
|
@@ -55,7 +66,9 @@ ensure separation of data.
|
55 | 66 | - Error-prone: Messing up the filtering can lead to data being leaked across users.
|
56 | 67 | - Scalability: As the number of users and documents grow, doing filtering on metadata can become slow.
|
57 | 68 |
|
58 |
| -## Doc-Per-Collection |
| 69 | +## User-Per-Collection |
| 70 | + |
| 71 | +The goal of this strategy is to grant a user access to all documents in a collection. |
59 | 72 |
|
60 | 73 | 
|
61 | 74 |
|
@@ -93,7 +106,10 @@ user.
|
93 | 106 | - Shared document search: If you want to maintain some documents shared then you will have to create a separate
|
94 | 107 | collection for those documents and allow users to query the shared collection as well.
|
95 | 108 |
|
96 |
| -## Doc-Per-Database |
| 109 | +## User-Per-Database |
| 110 | + |
| 111 | +The goal of this strategy is to associate a user with a single database thus granting them access to all collections and |
| 112 | +documents within the database. |
97 | 113 |
|
98 | 114 | 
|
99 | 115 |
|
@@ -143,12 +159,14 @@ In the above code we do the following:
|
143 | 159 | - We then create a `PersistentClient` for each user with the `tenant` and `database` we got from the `AdminClient`.
|
144 | 160 | - We then create or get collection and add data to it.
|
145 | 161 |
|
146 |
| - |
147 | 162 | **Drawbacks**:
|
148 | 163 |
|
149 | 164 | - This strategy requires consistent management of tenants and databases and their use in the client application.
|
150 | 165 |
|
151 |
| -## Doc-Per-Tenant |
| 166 | +## User-Per-Tenant |
| 167 | + |
| 168 | +The goal of this strategy is to associate a user with a single tenant thus granting them access to all databases, |
| 169 | +collections, and documents within the tenant. |
152 | 170 |
|
153 | 171 | 
|
154 | 172 |
|
|
0 commit comments