enter image description here
Now, you will work on a more complex scenario. Assume following roles are defined in an EHR
system. Now, before defining these roles in OpenMRS, try to combine the roles that can inherit
privileges from each other. You can define new roles if it makes managing your role hierarchy
easier. Report your role hierarchy.
Please help me with this exercise!!!
I wish someone could guide me on how to do this
Related
Since I had problem with Passport multi auth, I wonder is it necessary to have an admin guard (and an admins table) or it's better to use the default guard (and users table) for both admins and users with the help of role and permissions? Which is better?
That's a really hard question to answer without more information, but I'll try looking at it from a few perspectives:
You have an application that has users that can turn into admins (and vice-versa)
In this situation, I would probably have a single table that contains an is_admin column and use the column to validate whether the user can perform administration tasks (e.g. by using Laravel's gates). The downside to this is that if you wanted to create a third type of user (e.g. supervisor), you would need to change the model used.
You have an application where users are completely separate from administrators
If you control the administrators and everyone else is just a user, creating separate guards could be used, this does allow for a lot of flexibility in the future if you wanted to implement different authentication flows for both administrators and users (for example, using SAML). If you were to add a third type of user (e.g. supervisor), you could then just create another guard.
You have an application that can have different (customisable) permissions for each user
In this case I would recommend implementing a roles table, a permissions table, a role_permissions table and adding a column called role_id to the user table. This provides the most flexibility and is also usable with the Laravel's gate system, but is probably the most difficult to setup and hardest to maintain.
For the application I develop, we use a mixture of roles and guards. We use roles for users as each user gets a customisable set of permissions. We then use a separate guard for API users which inherit the permissions of the user they were authenticated with.
CRM 2015: I want to be able to create a role for local IT to be able to add user accounts and assign roles.
Regarding the 'adding roles' portion, is it simple enough just to create a role for local IT to 'write' to 'security' roles in the'business management' tab of 'security roles' at the user level?
No, this is not that simple. User cannot give another user privilege higher than he has (it would be a serious security hole). So for example you have role to edit Security roles and you have Read access for Accounts in your Business Units. If somebody in your Business unit has no Read access and only User access, you can add him Read access for Business Unit (the same you have), but you will not be able to give him Organizational access (so higher than yours). You could imagine that if this would be possible, you will be able to basically give yourself Admin privilege and do whatever you want in CRM.
Knowing that, it should be possible for you to create a role that for example have full access to Accounts, Contacts, Custom entities etc. and Security Roles. This role would be able to modify other users access levels to Accounts, Contacts etc. but no other entities that they don't have privilege to.
Exactly the same logic applies to assigning the Security Roles. So user A cannot assign a Security Role to user B, if it gives user B privileges higher than has User A.
In the end, it is very hard to properly implement the scenario that you described, because there are so many privileges and user needs to have a lot of them to even use the CRM. I've tried this once but could not satisfy the business requirement - it always ended up with using System Admin role, because there was always some scenario that could have not been handled by a user only with this "specific" security modification role.
Assigning 'System Administrator' security role and changing Access Mode in user record to 'Administrative' helped me to achieve this. User still cannot access any transaction data. So, I think you can go for this approach.
I am about to define permissions for users in my project. I checked the laracasts videos regarding ACL, Roles and Permissions.
I have a doubt. Do I need Roles for normal users?
I mean, in my project a user should be able to create / update / delete his own posts, he should be able to comment on his own posts and posts by other users and delete his posts and posts left by others on his own posts.
The point is: do I really need to define Roles for this kind of permissions? Shouldn't I just define some policies like can / can't post / update / delete etc. and only define roles for admins?
You don't necessarily need a full featured, powerful Roles/ACL system but if you are storing both admin and basic users in the same table then you do need something to distinguish between them. This could be something as simple as a Role field as a string on your users table e.g. Admin or Basic, or even a boolean is_admin field.
This would give you the ability to implement a Policy or Middleware to prevent basic users accessing the admin panel, and you can have permission checks to ensure a user can't update other users posts etc.
If you don't foresee needing anything more complex in future then this would suffice. However, as your app becomes more mature, you might wish to have a more advanced roles system, for example where a user needs to have multiple roles.
You don't necessarily need to define a role for every user...
It's probably a good idea to, however, you can 'hardcode' and make some assumptions about some of the access...
For example:
If you assume that anyone who is logged in can make a post and can edit their own post, you don't need to make a role for users to say "can_make_post", just have a check saying "if user is logged in, then let them make a post"
then if you say, have an admin area, then you can go "if user a has role
with the 'admin_access' permission, then allow access"
It would be a good idea to have roles for everything, as it allows more customisation, however, your the one designing it, if you don't need the customisation, you can probably just make some assumptions like above.
I am trying to come up with the best practice on how to set up roles for my controllers and actions.
We have a debate in our office. Should we give one role to the user and decorate our controllers and actions with a list or roles, or viceversa, multiples roles to an user and have controllers/actions decorated with the minumum access role required?
In my experience, it has been better to allow a user to assume multiple roles. This is the most flexible approach, and it will avoid an explosion in the number of roles in the system, because different people often wear different hats within an organization. This also simplifies your controllers/actions because you only need at most one role per.
I think this depends entirely on what you want your users to be doing. Is a person in an admin role only going to be able to do admin type things or everything?
We had a similar issue come up and we decided to go with 4 different roles and assigned multiple roles to users based on what they needed access to.
We are trying to implement Custom Role membership provider for our web app. For authorization we want to check for one more field like Facilityid for the logged on user along with role he has. eg. my User1 having Role1 with Facility1 can access some option and same user role for Facility2 have different option. So is there a way we can extend the existing role/profile provider to authorize user with this additional field along with role assigned.
Depending on how complicated you expect this to be you might want to just have Facility1 and Facility2 be roles, even though they may share a lot of the same aspects. In this manner, you should not need to extend the membership provider.
There can be n facilities so having those many roles does not look fesiable. If we can find a way by which we can pass the Facilityid from the application to this security module roleprovider and fetch appropriate role for user only for that facility.