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
Copy file name to clipboardExpand all lines: README.md
+211-1Lines changed: 211 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,9 @@ It provides three ways of integration
21
21
2.**Role based permissions** - Permissions are associated to roles and users have a specific role attached. This actually reduces redundancy in DB a lot, as most of the time, users will have many common permissions. If that is not the case for you, then, use method #1 above.
22
22
3.**Role based permissions with user level override** - This is the most flexible architecture. In this case, method #2 is implemented as is. On top of it, we also add user-level permissions override, allow/deny permissions over role permissions. So, say there is user who can perform all admin role actions except he cannot remove users from the system. So, DeleteUser permission can be denied at user level and role can be set as Admin for the user.
23
23
24
+
[Extension enhancement using CASBIN authorisation](#Extension-enhancement-using-CASBIN-authorisation)
25
+
26
+
24
27
Refer to the usage section below for details on integration
25
28
26
29
## Install
@@ -116,7 +119,6 @@ export class User extends Entity implements UserPermissionsOverride<string> {
116
119
}
117
120
}
118
121
```
119
-
120
122
- For method #3, we also provide a simple provider function [_AuthorizationBindings.USER_PERMISSIONS_](<[./src/providers/user-permissions.provider.ts](https://github.com/sourcefuse/loopback4-authorization/blob/master/src/providers/user-permissions.provider.ts)>) to evaluate the user permissions based on its role permissions and user-level overrides. Just inject it
# Extension enhancement using CASBIN authorisation
273
+
274
+
As a further enhancement to these methods, we are using [casbin library!](https://casbin.org/docs/en/overview) to define permissions at level of entity or resource associated with an API call. Casbin authorisation implementation can be performed in two ways:
275
+
1.**Using default casbin policy document** - Define policy document in default casbin format in the app, and configure authorise decorator to use those policies.
276
+
2.**Defining custom logic to form dynamic policies** - Implement dynamic permissions based on app logic in casbin-enforcer-config provider. Authorisation extension will dynamically create casbin policy using this business logic to give the authorisation decisions.
277
+
278
+
## Usage
279
+
280
+
In order to use this enhacement into your LoopBack application, please follow below steps.
281
+
282
+
- Add providers to implement casbin authorisation along with authorisation component.
- Implement the **Casbin Resource value modifier provider**. Customise the resource value based on business logic using route arguments parameter in the provider.
thrownewHttpErrors.InternalServerError(`Metadata object not found`);
324
+
}
325
+
const res =metadata.resource;
326
+
327
+
// Now modify the resource parameter using on path params, as per business logic.
328
+
// Returning resource value as such for default case.
329
+
330
+
return`${res}`;
331
+
}
332
+
}
333
+
334
+
```
335
+
- Implement the **casbin enforcer config provider** . Provide the casbin model path. In case 1 of using [default casbin format policy!](https://casbin.org/docs/en/how-it-works), provide the casbin policy path. In other case of creating dynamic policy, provide the array of Resource-Permission objects for a given user, based on business logic.
If you've noticed a bug or have a question or have a feature request, [search the issue tracker](https://github.com/sourcefuse/loopback4-authorization/issues) to see if someone else in the community has already created a ticket.
0 commit comments