How can I group the permissions using Picketlink[1] in such a way that I can assign one or more especific Groups of permissions to a Role ?
Thanks in advance.
Have you read the official documentation before asking?
If yes, showing us your efforts would make it easier to help you.
If not, please take a look at this.
I'm asking you this for a reason: I think you've misunderstood the concepts of Group, Role and Permission.
A Group is used to manage collections of identity types. For instance, Alice and Bob could be User identities which are member of "employees" group.
The Role is used in various relationship types to designate authority to another identity type to perform various operations within an application.
For example, Trent could be an User identity with the role of "moderator".
Permissions can be assigned to User, Groups and Roles.
It's up to you to choose in which way(s) to manage permissions in your application.
Access control can be based on Groups ("only employees can use this method"), Roles ("only moderators can delete posts") or even Users ("I am the only one who can eat bacon here!"). This can be done with the use of the Permission API, as explained in the documentation linked above.
Trust me, I know it could be not so simple at first - but please make an effort; then feel free to ask anything :)
Let us know!
Answer to comments
As you said, PicketLink's Permission API only lets you assign one permission at a time.
Anyways, note that even if you have to grant one permission at a time, this doesn't mean you can't grant multiple permissions to an instance:
permissionManager.grantPermission(adminRole, resource, myPermissions.CREATE)
permissionManager.grantPermission(adminRole, resource, myPermissions.DELETE)
permissionManager.grantPermission(adminRole, resource, myPermissions.UPDATE)
grants 3 permissions to every user that has adminRole and needs to invoke resource.
Related
I need to implement an authentication system where a super admin can create multiple different roles with different rights for users. That is, not a system with a set number of roles, but have the option to create as many roles with different combination of rights as the superadmin wants, and then assign them to new users. Also with the option of editing these roles, deleting them etc. I'm fairly new at Node Js. Is this something hard to implement? Are there any articles/videos I can read/watch, to start understanding the process? Where do I start? I'd really appreciate any help. Thank you in advance!
You're thinking about Role-Based Access Control (RBAC). I have actually implemented this in Node.js before, feel free to checkout how I implemented it here: https://github.com/JLCarveth/nodeblog.
It's relatively simple. You need a table for tracking roles. Each role has 0 or more permissions. These permissions can be comma-separated strings, or IDs referencing a permissions table. Each user is then assigned a role.
Each route is protected with a middleware that specifies the needed permissions. If a user accesses this route, check that they have the necessary permissions and continue, reject if not.
I am creating an application that uses Azure AD user groups to grant permissions to specific resources. For example, a particular set of documents can only be accessed by users in specific groups. The application receives the group ids as claims on the JWT and ensures that only documents assigned to groups in the claims are visible.
Now, the question is how to manage groups correctly in Azure AD. When users are assigned to a group become a member of that group and any groups that group is nested in. This seems to imply that my group nesting should be the reverse of the tree structure I would like. Something like this:
Admin --> member of --> Group with most access --> member of --> group with less access --> member of --> group with least access.
To me this seems backwards but it provides the correct access rights to users added to each group.
Am I way off base here or is this a reasonable way to manage access rights with AD groups?
#JoyWang already covered some good points in answer above. Here are some additional considerations. Disclaimer: Due to nature of question, my answer here is mostly opinion and learning from some cases. Idea is to share how I have seen groups getting used along with some related info.
Are the groups specific to your application or more general purpose? Group membership and nested groups are usually used to organize users & groups logically/intuitively rather than design permissions for specific application
Many times Azure AD Groups are used by more than one application and may have a lifetime longer than any one specific application you're developing.
The way you are thinking about nesting groups based on which one has more access v/s less access you're probably concerned about only one particular application that you're developing and thinking about a group's access to this application. This approach will work out if the groups you plan to create are also very application specific and will NOT be used for any other purpose.
Example1: Your application is a blogging app and groups you create in Azure AD are Viewer, Contributor and Admin. (Admin > Contributor > Viewer)
Example2: You have an enterprise using Azure AD and groups organize users logically, say deparatment wise Marketing, Human Resources, Engineering etc.
So, the way you describe nested groups based on lower access permissions to higher, it will technically work out for a simpler scenario like in Example1 but not for Example2 where groups are more general purpose.
Many times general purpose groups already exist and you're expected to reuse them rather than create new ones for your application which require new assignments/membership all over again, but this may or may not be applicable in your specific case.
Also, there can be multiple people managing these groups and their membership so any design/organization pattern you come up with should give importance to intuitiveness even if you have to sacrifice minor application specific efficiency sometimes.
In my opinion, you can look at both flat or nested groups.. if it makes sense from an organization of users and groups standpoint, not just access permissions. Another fictious example: Marketing Group can have a member group like Marketing Content Approvers because it's a subset of Marketing people.
Do consider Application Roles.
They are specific to an application, tied to it's manifest and can be available to you as part of claims in token.
There can be situations like individual resource based access where you want to give permissions to a specific resource where Application Roles may or may not make sense and you still need to rely on groups or users directly. In any case, it's another helpful option available to you.
Managing Groups (as you've asked about this in comments)
Take a look at Self Service Group Management Scenarios (Delegated v/s Self-service) and also Dynamic Groups for dynamic membership rules based on attributes (requires Premium license though).
In AAD, the permissions of a member in the groups depend on the biggest permission of the group which he is a member of. For example, group A can access a resource and group B can't access it, the man is both in group A and B, then he will be able to access the resource.
To me this seems backwards but it provides the correct access rights to users added to each group.
Let we call the three groups as A,B,C, the permission of them is A > B >C. Obviously, if you add A to B, the permissions of A and B both have not been affected. But if you add B to A, the members in A or B will both have the biggest permission, it is no what you want. The same with B and C. This is why it provides the correct access rights to users added to each group as you said.
So in my personal opinion, seems no need to use nested groups, just use three groups with different permissions, it's enough.
After reading http://en.wikipedia.org/wiki/Role-based_access_control and seeing the way people are building authorization/access control, this question came to my mind "Why we are checking roles of users when checking if they are permitted to do X rather than checking their permissions?"
This is what I understood, Users have Roles, Roles have permission and this is how a user can have permissions (A user cannot explicitly have permissions assigned to it, it gets its permission by having roles)
And I think it makes sense to check for a permission like "AddUser" when processing a request for adding a user but in .Net library and also in a lot of examples in RBAC we see that they check for Roles. Like they check if the user is in the role of Administrators rather than checking if he/she has the permission "AddUser".
Why? It kind of makes more sense to me to check for permissions.
Can someone please illuminate me here?
Thanks
You are correct - checking for roles in applications instead of permissions is not Role-Based Access Control. Spring security and many other prominent access control mechanisms propagate this security anti-pattern. For correct RBAC usage - perform permission checks in your policy enforcement logic.
If we simplify the RBAC system, RBAC is a method of restricting access to 'some sources or applications or some features of applications' based on rights of users of organization. Here, restrictions can be by means of multiple permissions, those are created by administrator to restrict access, and these permissions collectively represents a role, which will be assigned to user.
You might be partially true for your case :)
But consider a case of complex application, where there are 200 permissions, and administrators need to define few set of permissions to represent specific behavior via role, which will create some complex kind of customization and re presentation of the form for that user.
Here it might be required to check via ‘HasRole(‘SomeRole’)’ method to define exact behavior of user.
So, my answer would be, both methods are equally important in RBAC.
1) HasPermission(‘permissionName’)
2) HasRole(‘roleName’)
A good RBAC solution should provide both these methods. There are such tools available in the market, you can check for them.
I have three custom entities; Project, ProjectStageExternal and ProjectStageInternal,I have added a workflow which will create ProjectStageInternal and ProjectStageExternal records when admin creates a Project record.
Now I have a security roll named customer. Users having this roll only read the Project and ProjectStageExternal records.
The problem is workflow is not working when ownership is changed to users having customer security roll. Its showing this following error: The selected user does not have sufficient privileges to be assigned records of this type.
what am I missing here?
Thanks.
That security role has basically no permissions on those entities, so the users wont be able to do anything with them.
If you want someone to be able to assign (or have a workflow assign on their behalf) you need to grant the assign permission and probably write as well.
If you dont want to grant them those permissions, change the workflow's Scope to organisation and assign it to an admin user. That means the workflow will run with the admins permissions and security roles.
Only providing Read Privileges to the user/team whom the record is to be assigned will work perfectly fine !!
I want to find whether a user in a site has been granted permissions directly or he is inheriting permissions from a group. How can I do that using SharePoint object model?
I dont think there is a direct way to do this. One option is to get all the groups he is in and then see if this group belongs to a another group. If so then he is inheriting the permission from the group. Not a good solution though. :-)