Replies: 3 comments
-
The Permissions service is designed to be extensible.... so yes, you can use your own custom entities as well as custom permissions. You can also define your own custom roles. So essentially there are 3 different dimensions that are available to you. Note that an entity typically refers to a data domain (ie. Page, Module, etc... ) which has a unique identifier and a set of attributes for each entity. Permissions refer to specific types of user interactions (ie. Edit, View, etc... ). And roles refer to access rights for groups of users (ie. Administrator, Editor, etc...). It is not clear to me what you are trying to accomplish so I do not know if entities, permissions, or roles are the appropriate extensibility point for you. |
Beta Was this translation helpful? Give feedback.
-
An example of a claim in this instance might be a user that can see a sub-set of the data. Imagine a reporting portal where a user has access to the page but we only want to report on a subset of the data as it applies to them. We could theoretically build a site for every customer and then give them permissions to a site (by extending permissions) but that would be a lots of sites. If we wanted to keep them on one site and then break things out by project (an arbitrary sub-set of the data) then we could create a "project" permission and assign folks to projects. This would be similar to roles, but more like a claim. Pages navigation and edit capabilities would not change, but if we wanted to filter some data coming out of an API based on the user, I see how that could work using Oqtane Permissions. More research on the permissions code, but it sounds right so far. |
Beta Was this translation helpful? Give feedback.
-
@markdav-is when I think of "claims" I think of the OAuth definition where a claim is a name/value pair that contains information about a specific user. In this context a Role is a type of claim - and a user can be a member of many Roles, so a user could have multiple Role claims (as well as an ID claim, Email claim, etc.. ). I am not sure if this matches your expectation for a "claim"? Either way, I understand the use case you are trying to solve... and essentially it comes down to the sharding of data. Oqtane actually uses this approach internally - a good example is how it loads the pages for a site and filters them to only include the pages to which a user has permissions. In this scenario a Page is an entity (ie. it has a unique ID and attributes) and there are 2 permissions defined - View and Edit. An administrator defines which Roles/Users have View permission and Edit permission for each Page via the Permission Grid. Then when the framework loads the list of pages it uses these permissions to filter the list. You can follow this same pattern for any custom entity. So in practical terms, you would create a Client entity (which is a standard entity with an ID and some attributes). The entity will allow you to shard data in any dependent entities (ie. Projects, etc...) You will also need to create individual roles for each client (ie. Client1, Client2, etc...) so that you can assign users to these roles. You would probably want to create a module to manage Clients. The module could leverage the permission grid component to allow an administrator to map users/roles to permissions for each Client entity (you can use the PermissionNames parameter on the permission grid to provide a comma delimited list of permissions you want to manage). Permissions would be stored in the standard permissions service. Your API methods for getting Client data would leverage the user's context and permission assignments to perform the validation/filtering (the framework already has support for this). Note that it may be tempting to use a simpler convention-based approach and associate a single role to each Client - however this usually causes refactoring issues in the future when you need to add support for a new type of role or permission. |
Beta Was this translation helpful? Give feedback.
-
We have a need to provide a smaller granularity of permissions within Oqtane. For instance, we have clients that will login, and these clients will have a Client role assigned to them, but we need to ensure that one client does not see another client's data. I am wondering if we can use the Permissions table with our own Entity types, like EntityName = "Client" EntityValue = "ABC" where ABC is the client's code.
Beta Was this translation helpful? Give feedback.
All reactions