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 hit the website to access the singlepage application, the Light Gateway will serve the single page application on users browser. By default, the user is not logged in and he/she can only access limited features on the site. If the user want to access more features, he/she can click the user button on the header and click sign in menu. This will allow the browser to redirect from the Portal View to Login View which is served by the same instance of Light Gateway.</p>
201
+
<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>
196
202
</li>
197
203
<li>
198
-
<p>On the Login View site, he/she can input the username/password or choose Google/Facebook for authentication. Once the Signin form is submitted, the request goes to the Light Gateway with user credentials. The Light Gateway will route the request to the OAuth Kafka service.</p>
204
+
<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>
199
205
</li>
200
206
<li>
201
-
<p>OAuth Kafka has many Authenticator implementations that can be used to authenticate the user credential. For example, use the Light Portal user database to authenticate, use Active Directory to authenticate employees or use CIF service to authenticate customers.</p>
207
+
<p>OAuth Kafka supports multiple authenticator implementations to verify user credentials. Examples include authenticating via the Light Portal user database, Active Directory for employees, or CIF service for customers.</p>
202
208
</li>
203
209
<li>
204
-
<p>Once authentication is completed successfully, it will response to the OAuth Kafka with the authentication result.</p>
210
+
<p>Once authentication is successfully completed, the OAuth Kafka responds with the authentication result.</p>
205
211
</li>
206
212
<li>
207
-
<p>Upon successful authentication, OAuth Kafka will generate an authorization code which is a UUID associated to the user profile.</p>
213
+
<p>Upon successful authentication, OAuth Kafka generates an authorization code (a UUID associated with the user's profile).</p>
208
214
</li>
209
215
<li>
210
-
<p>OAuth Kafka redirect the authorization code to the Portal View browser through Gateway.</p>
216
+
<p>OAuth Kafka redirects the authorization code back to the browser at the Portal View via the Gateway.</p>
211
217
</li>
212
218
<li>
213
-
<p>The Portal View single page application doesn't have this redirct route, so that request will be sent to the Gateway with the code as a query parameter.</p>
219
+
<p>Since the Portal View SPA lacks a dedicated redirect route for the authorization code, the browser sends the code as a query parameter in a request to the Gateway.</p>
214
220
</li>
215
221
<li>
216
-
<p>The StatelessAuthHandler on the Gateway will handle the request and send a token request to the OAuth Kafka to get a JWT access token.</p>
222
+
<p>The <code>StatelessAuthHandler</code> in the Gateway processes this request, initiating a token request to OAuth Kafka to obtain a JWT access token.</p>
217
223
</li>
218
224
<li>
219
-
<p>OAuth Kafka will generate an access token with user claims in the JWT custom claims and drop the code as it is used only once.</p>
225
+
<p>OAuth Kafka generates an access token containing user claims in its custom JWT claims. The authorization code is then invalidated, as it is single-use.</p>
220
226
</li>
221
227
<li>
222
-
<p>The authorization code token is returned to the Gateway.</p>
228
+
<p>The access token is returned to the Gateway.</p>
223
229
</li>
224
230
<li>
225
-
<p>The StatelessAuthHandler on the Gateway will put the token into a secure cookie and send to the Portal View.</p>
231
+
<p>The <code>StatelessAuthHandler</code> in the Gateway stores the access token in a secure cookie and sends it back to the Portal View.</p>
226
232
</li>
227
233
<li>
228
-
<p>When Portal View access one of the Backend APIs, it sends the API request to the Gateway with the cookies.</p>
234
+
<p>When the Portal View SPA makes requests to backend APIs, it includes the secure cookie in the API request sent to the Gateway.</p>
229
235
</li>
230
236
<li>
231
-
<p>The StatelessAuthHandler on the Gateway will verify the token in the secure cookie and put it into the Authorization header of the request.</p>
237
+
<p>The <code>StatelessAuthHandler</code> in the Gateway validates the token in the secure cookie and places it in the <code>Authorization</code> header of the outgoing request.</p>
232
238
</li>
233
239
<li>
234
-
<p>Once the token is verified successfully, the TokenHandler on the Gateway will issue a token request to get a client credentials token to the OAuth Kafka based on the path prefix of the API endpoint.</p>
240
+
<p>If the token is successfully validated, the <code>TokenHandler</code> in the Gateway makes a request to OAuth Kafka for a client credentials token, using the path prefix of the API endpoint.</p>
235
241
</li>
236
242
<li>
237
-
<p>OAuth Kafka generate a client credentials token with the scope that can access the downstream service.</p>
243
+
<p>OAuth Kafka generates a client credentials token with the appropriate scope for accessing the downstream service.</p>
238
244
</li>
239
245
<li>
240
246
<p>The client credentials token is returned to the Gateway.</p>
241
247
</li>
242
248
<li>
243
-
<p>The TokenHandler on the Gateway will put this token into X-Scope-Token header of the original request.</p>
249
+
<p>The <code>TokenHandler</code> in the Gateway inserts this token into the <code>X-Scope-Token</code> header of the original request.</p>
244
250
</li>
245
251
<li>
246
-
<p>The Gateway router the original requestto the downstream Backend API.</p>
252
+
<p>The Gateway routes the original request, now containing both tokens, to the downstream <code>proxy sidecar</code>of the backend API.</p>
247
253
</li>
248
254
<li>
249
-
<p>The Backend API will verify the Authorization token for the signatureand expiration etc.</p>
255
+
<p>The proxy sidecar validates the <code>Authorization</code> token, verifying its signature, expiration, and other attributes.</p>
250
256
</li>
251
257
<li>
252
-
<p>The Backend API will verify the X-Scope-Token for signature, expiration and scope etc.</p>
258
+
<p>The proxy sidecar also validates the <code>X-Scope-Token</code>, ensuring its signature, expiration, and scope are correct.</p>
253
259
</li>
254
260
<li>
255
-
<p>The Backend API retuns the response once both tokens are verified.</p>
261
+
<p>Once both tokens are successfully validated, the proxy sidecar enforces fine-grained authorization rules based on the user's custom security profile contained in the <code>Authorization</code> token.</p>
256
262
</li>
257
263
<li>
258
-
<p>The response returns to the Portal View to render the page.</p>
264
+
<p>If the fine-grained authorization checks are passed, the proxy sidecar forwards the request to the backend API.</p>
265
+
</li>
266
+
<li>
267
+
<p>The backend API processes the request and sends the full response back to the <code>proxy sidecar</code>.</p>
268
+
</li>
269
+
<li>
270
+
<p>The proxy sidecar applies fine-grained filters to the response, reducing the number of rows and/or columns based on the user's security profile or other policies.</p>
271
+
</li>
272
+
<li>
273
+
<p>The proxy sidecar returns the filtered response to the Gateway.</p>
274
+
</li>
275
+
<li>
276
+
<p>The Gateway forwards the response to the Portal View, allowing the SPA to render the page.</p>
<h2id="what-is-fine-grained-authorization"><aclass="header" href="#what-is-fine-grained-authorization">What is Fine-Grained Authorization?</a></h2>
157
+
<p>Fine-grained authorization (FGA) refers to a detailed and precise control mechanism that governs access to resources based on specific attributes, roles, or rules. It's also known as fine-grained access control (FGAC). Unlike coarse-grained authorization, which applies broader access policies (e.g., "Admins can access everything"), fine-grained authorization allows for more specific policies (e.g., "Admins can access user data only if they belong to the same department and the access request is during business hours").</p>
<li><strong>Granular Control</strong>: Policies are defined at a detailed level, considering attributes like user role, resource type, action, time, location, etc.</li>
161
+
<li><strong>Context-Aware</strong>: Takes into account dynamic conditions such as the time of request, user’s location, or other contextual factors.</li>
162
+
<li><strong>Flexible Policies</strong>: Allows the creation of complex, conditional rules tailored to the organization’s needs.</li>
163
+
</ul>
164
+
<h2id="why-do-we-need-fine-grained-authorization"><aclass="header" href="#why-do-we-need-fine-grained-authorization">Why Do We Need Fine-Grained Authorization?</a></h2>
<p>It helps organizations comply with legal and industry-specific regulations (e.g., GDPR, HIPAA) by ensuring sensitive data is only accessible under strict conditions.</p>
<p>By restricting access to only the required resources and operations, fine-grained authorization reduces the potential impact of insider threats or compromised accounts.</p>
171
+
<h3id="4-improved-user-experience"><aclass="header" href="#4-improved-user-experience">4. <strong>Improved User Experience</strong></a></h3>
172
+
<p>Enables personalized access based on roles and permissions, ensuring users see only what they need, which reduces confusion and improves productivity.</p>
173
+
<h3id="5-auditing-and-accountability"><aclass="header" href="#5-auditing-and-accountability">5. <strong>Auditing and Accountability</strong></a></h3>
174
+
<p>Detailed access logs and policy enforcement make it easier to track and audit who accessed what, when, and why, fostering better accountability.</p>
175
+
<h2id="examples-of-use-cases"><aclass="header" href="#examples-of-use-cases">Examples of Use Cases</a></h2>
176
+
<ul>
177
+
<li><strong>Healthcare</strong>: A doctor can only view records of patients they are treating.</li>
178
+
<li><strong>Government</strong>: A government employee can access to data and documents based on security clearance levels and job roles.</li>
179
+
<li><strong>Finance</strong>: A teller can only access transactions related to their assigned branch.</li>
180
+
<li><strong>Enterprise Software</strong>: Employees can edit documents only if they own them or have been granted editing permissions.</li>
181
+
</ul>
182
+
<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
+
<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>
0 commit comments