- ABP Framework version: c4.0.0
- UI type: MVC
- Tiered (MVC) or Identity Server Seperated (Angular): yes
- MongoDB
- Exception message and stack trace:
- Steps to reproduce the issue:
Hi,
The existing OU functionality allows us to define a hierarchy of OUs and then specify the users which are within the OUs. We are then able to define the roles for an OU, which results in those roles being applied to the users within the OU.
However, we have a requirement where we need to able to assign a role to a user, which should only give them the role permissions for the specific organizational units defined by the role.
The idea would be the following.
- Be able to create a role and be able to indicate that it is a "Restricted Access" role (it would just be an extension of the existing role entity) and specify which organization units the role functionality is applicable to.
- it does not grant its permissions globally, but only for data within the specified organization units.
- Be able to choose which organization unit(s) the the role applies to
- The permissions enabled by the role will be limited to those that support restricted access (as it is up to the services / repositories to ensure that they can filter by OU).
- A user does not need to be in the orgnization unit to be assigned the role
- Assign the role to user/organisation units/api clients in the usual way
- As it is a normal role (with some additional properties), this will mean that it will work for the usual role functionality and security checks within razor pages and services
- Within the services the data can be filtered and actions restricted so that they are ou specific
I have looked at all the existing documentation regarding organization units and looked at many existing software solutions to discover how it works from a users perspective and I believe the above design would work well.
I am wondering if you are planning to extend the OU functionality to include this feature in the future? Or anything similar? Is there already a request of backlog item for it?
If not, are you able to make any recommendations about how we should go about implementing this functionality?
My current thinking is
- Extend the permissions system to be able to define permissions as "Restricted Access"
- This is needed because not all permissions will support filtering by OU
- Extend the role creation / editor
- to be able to indicate that a role is "Restricted Access"
- to be able to select the "Restricted Access" permissions which are enabled for the role
- Extend relative entities so that they can be included in an OU.
- We might want to support entities existing in more thatn on OU
- Extend my services / repositories to do the required filtering
- Make the design flexible enough that we can override and extend existing modules to make the support the "Restricted Access" concept
I settled on the "Restricted Access" rather than "OU Specific" as I think "OU Specific" does not make it clear what its purpose is and can be confused with the existing ability to add roles to an OU. I also chose to extend permissions to be "Restricted Access" and to make a distinction between normal roles vs "Restricted Access" roles to make it clear what a user with the role will be able to do and there would be no confusion about if the user will have access to all data or only data associated with particular OUs.
Your help is greatly appreciated,
Mike
2 Answer(s)
-
0
Hello Mike,
Roles, permissions, operations; generally whole authorization aspect varies according to the context it is used and in the business rules it is dealth with. In some application you can see users logging to that system with different roles they have (mostly in legacy RBAC systems); in some other systems they login with same account and authorization is handled by operations, permissions, claims etc.
If I understand your idea correctly, you want to distinguish user roles and organization roles. So that organization unit roles can be extended from user roles. However this will only complicate the authorization even more.
How about moving the "Restricted Access" logic to claims and build around it? May I suggest you to check out role claims if it can suit your purpose?
-
0
Many thanks for your feedback.
I ended up extending my relevant entities to include a collection of OU ids and duplicated the same UI in the entity create / edit modal views (e.g. JTree), which exists for assigning a user to one or more OUs.
I then did what you suggested and created a custom claim type (added to user or role claims), which needed to be set to the id of the relevant OU that a user would have access to.
I then updated my repository to filter based on the relevant OU ids (discovered by checking the user claims and getting all child OUs using the
OrganizationUnitManager.I had to fix a bug which was preventing me from saving claims against individual roles.
Thanks again.
