You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>When a user visits the website to access the single-page application (SPA), the Light Gateway serves the SPA to the user's browser. By default, the user is not logged in and can only access limited site features. To unlock additional features, the user can click the <strong>User</strong> button in the header and select the <strong>Sign In</strong> menu. This action redirects the browser from the Portal View to the Login View, both served by the same Light Gateway instance.</p>
239
+
<p>When a user visits the website to access the single-page application (SPA), the Light Gateway serves the SPA to the user's browser. Each single page application will have a dedicated Light Gateway instance acts as a BFF. By default, the user is not logged in and can only access limited site features. To unlock additional features, the user can click the <code>User</code> button in the header and select the <code>Sign In</code> menu. This action redirects the browser from the Portal View to the Login View, both served by the same Light Gateway instance.</p>
202
240
</li>
203
241
<li>
204
242
<p>On the Login View page, the user can either input a username and password or choose Google/Facebook for authentication. When the login form is submitted, the request is sent to the Light Gateway with the user's credentials. The Gateway forwards this request to the OAuth Kafka service.</p>
@@ -323,6 +361,8 @@ <h3 id="sequence-diagram"><a class="header" href="#sequence-diagram">Sequence Di
<h2id="fine-grained-authorization-in-api-access-control"><aclass="header" href="#fine-grained-authorization-in-api-access-control">Fine-Grained Authorization in API Access Control</a></h2>
183
183
<p>In API access control, fine-grained authorization governs how users or systems interact with specific API endpoints, actions, and data. This approach ensures that access permissions are precisely tailored to attributes, roles, and contextual factors, enabling a secure and customized API experience. As the Light Portal is a platform centered on APIs, the remainder of the design will focus on the API access control context.</p>
<h2id="early-approaches-to-fine-grained-authorization"><aclass="header" href="#early-approaches-to-fine-grained-authorization">Early Approaches to Fine Grained Authorization</a></h2>
185
+
<p>Early approaches to fine grained authorization primarily involved Access Control Lists (ACLs) and Role-Based Access Control (RBAC). These methods laid the foundation for more sophisticated access control mechanisms that followed. Here's an overview of these primary approaches:</p>
186
+
<h3id="access-control-lists-acls"><aclass="header" href="#access-control-lists-acls">Access Control Lists (ACLs):</a></h3>
187
+
<ul>
188
+
<li>
189
+
<p>ACLs were one of the earliest forms of fine grained authorization, allowing administrators to specify access permissions on individual resources for each user or group of users.</p>
190
+
</li>
191
+
<li>
192
+
<p>In ACLs, permissions are directly assigned to users or groups, granting or denying access to specific resources based on their identities.</p>
193
+
</li>
194
+
<li>
195
+
<p>While effective for small-scale environments with limited resources and users, ACLs became cumbersome as organizations grew. Maintenance issues arose, such as the time required to manage access to an increasing number of resources for numerous users.</p>
196
+
</li>
197
+
</ul>
198
+
<h3id="role-based-access-control-rbac"><aclass="header" href="#role-based-access-control-rbac">Role-Based Access Control (RBAC):</a></h3>
199
+
<ul>
200
+
<li>
201
+
<p>RBAC emerged as a solution to the scalability and maintenance challenges posed by ACLs. It introduced the concept of roles, which represent sets of permissions associated with particular job functions or responsibilities.</p>
202
+
</li>
203
+
<li>
204
+
<p>Users are assigned one or more roles, and their access permissions are determined by the roles they possess rather than their individual identities.</p>
205
+
</li>
206
+
<li>
207
+
<p>RBAC can be implemented with varying degrees of granularity. Roles can be coarse-grained, providing broad access privileges, or fine-grained, offering more specific and nuanced permissions based on organizational needs.</p>
208
+
</li>
209
+
<li>
210
+
<p>Initially, RBAC appeared to address the limitations of ACLs by providing a more scalable and manageable approach to access control.</p>
211
+
</li>
212
+
</ul>
213
+
<h3id="both-acls-and-rbac-have-their-shortcomings"><aclass="header" href="#both-acls-and-rbac-have-their-shortcomings">Both ACLs and RBAC have their shortcomings:</a></h3>
214
+
<ul>
215
+
<li>
216
+
<p>Maintenance Challenges: While RBAC offered improved scalability compared to ACLs, it still faced challenges with role management as organizations expanded. The proliferation of roles, especially fine grained ones, led to a phenomenon known as <strong>role explosion</strong> where the number of roles grew rapidly, making them difficult to manage effectively.</p>
217
+
</li>
218
+
<li>
219
+
<p>Security Risks: RBAC's flexibility also posed security risks. Over time, users might accumulate permissions beyond what they need for their current roles, leading to a phenomenon known as <strong>permission creep</strong>. This weakened overall security controls and increased the risk of unauthorized access or privilege misuse.</p>
220
+
</li>
221
+
</ul>
222
+
<p>Following the discussion of early approaches to fine grained authorization, it's crucial to acknowledge that different applications have varying needs for authorization.</p>
223
+
<p>Whether to use fine grained or coarse-grained controls depends on the specific project. Controlling access becomes trickier due to the spread-out nature of resources and differing levels of detail needed across components. Let’s delve into the differentiating factors:</p>
224
+
<h2id="standard-models-for-implementing-fga"><aclass="header" href="#standard-models-for-implementing-fga">Standard Models for Implementing FGA</a></h2>
225
+
<p>There are several standard models for implementing FGA:</p>
226
+
<ul>
227
+
<li>
228
+
<p><code>Attribute-Based Access Control (ABAC)</code>: In <ahref="https://en.wikipedia.org/wiki/Attribute-based_access_control">ABAC</a>, access control decisions are made by evaluating attributes such as user roles, resource attributes (e.g., type, size, status), requested action, current date and time, and any other relevant contextual information. ABAC allows for very granular control over access based on a wide range of attributes.</p>
229
+
</li>
230
+
<li>
231
+
<p><code>Policy-Based Access Control (PBAC)</code>: <ahref="https://www.nextlabs.com/what-is-policy-based-access-control/">PBAC</a> is similar to ABAC but focuses more on defining policies than directly evaluating attributes. Policies in PBAC typically consist of rules or logic that dictate access control decisions based on various contextual factors. While ABAC relies heavily on data (attributes), PBAC emphasizes using logic to determine access.</p>
232
+
</li>
233
+
<li>
234
+
<p>Relationship-Based Access Control (ReBAC): <ahref="https://en.wikipedia.org/wiki/Relationship-based_access_control">ReBAC</a> emphasizes the relationships between users and resources, as well as relationships between different resources. By considering these relationships, ReBAC provides a powerful and expressive model for describing complex authorization contexts. This can involve the attributes of users and resources and their interactions and dependencies.</p>
235
+
</li>
236
+
</ul>
237
+
<p>Each of these models offers different strengths and may be more suitable for different scenarios. FGA allows for fine grained control over access, enabling organizations to enforce highly specific access policies tailored to their requirements.</p>
238
+
<h2id="streamlining-fga-by-implementing-rule-based-access-control"><aclass="header" href="#streamlining-fga-by-implementing-rule-based-access-control">Streamlining FGA by Implementing Rule-Based Access Control:</a></h2>
239
+
<p>ABAC (Attribute-Based Access Control) focuses on data attributes, PBAC (Policy-Based Access Control) centers on logic, and ReBAC (Relationship-Based Access Control) emphasizes relationships between users and resources. But what if we combined all three to leverage the strengths of each? This is the idea behind <strong>Rule-Based Access Control (RBAC)</strong>.</p>
240
+
<p>By embedding a lightweight rule engine, we can integrate multiple rules and actions to achieve the following:</p>
241
+
<ul>
242
+
<li>
243
+
<p><strong>Optimize ABAC</strong>: Reduce the number of required attributes since not all rules depend on them. For example, a standard rule like <em>"Customer data can only be accessed during working hours"</em> can be shared across policies.</p>
244
+
</li>
245
+
<li>
246
+
<p><strong>Flexible Policy Enforcement</strong>: Using a rule engine makes access policies more dynamic and simpler to manage.</p>
247
+
</li>
248
+
<li>
249
+
<p><strong>Infer Relationships</strong>: Automatically deduce relationships between entities. For instance, the rule engine could grant a user access to a file if they already have permission for the containing folder.</p>
0 commit comments