i'm looking for a way to create users groups in Vanilla Forum (Vanilla is an open-source community-building solution)
The goal is allowing users, registered in a certain group, reading and editing only discussions created by users registered in the same group.
Example:
Group 1 Users --> read & write only in Group 1 Discussions.
Group 2 Users --> read & write only in Group 2 Discussions.
....
Group N Users --> read & write only in Group N Discussions.
Someone know if it is possible?
Vanilla Forums uses a system called "Roles and Permissions" to manage access rights for groups of users. You'll find the Roles and Permissions link in your Dashboard (specifically, /dashboard/role).
When you create a category, you can assign it custom permissions for each defined Role in your application, allowing you to exclude some people but allow others in, either to post, read, or both.
Related
I am running Kentico 11. I have a section of the site that requires user login to read and download some hidden content.
Those users are stored in the Configuration -> Users table. I have a custom Role that these users are assigned to so they can login and view the content & download files. We have an external (CRM) system that is integrated with Kentico. This CRM automates the User account creation & Role assignment based on yearly training records. So the user accounts do not get manually created. CRM manages the creation & deactivation. This is working as intended with 1,000s of users.
Business requirements have changed and now requires two levels of access. Will require a 2nd Role be created. First tier will allow basic access to content. A new 2nd tier (additional Role) will allow access to the file downloads.
The first tier will remain managed by the 3rd party integration from CRM (account & 1st role assigned). The 2nd tier will have to be manually controlled. Someone will have to login to Kentico, Configuration -> Users. Search for the user and add the 2nd Role.
To avoid putting the burden on the programmers I need to allow some of my non-technical team (customer support, product management) to be able to manage the Users.
These non-technical do not have Kentico CMS accounts. I do not want to make them Administrator and give them "keys to everything".
My question is specific to Configuration -> Permissions -- can I give my non-technical team the Read permission to "CMS Basic User" and Manage User Roles "Contractor" (and my custom role 1st ) and expect that they will be able to login to Kentico, navigate to Users and maintain my Contractors.
This is expected to allow them to view my contractors, and add them to a new 2nd role "Contractor Download". Take bob.smith#someemail.com for example. Bob is a contractor, the CRM tool added him to the Users Table with the roles Authenticated, Everyone and Contractor. Bob has completed some training and now needs the Contractor Download role.
Is the appropriate best-practice in Kentico to give my non-technical staff the CMS Basic User role & Contractor Role so they can manage our contractors? Is there a risk to this configuration? Will they be able to manage other roles? I do not want them to be able to edit content management, ecommerce or any other configurations.
It can be hard to give permission to manage one role but not the other. Usually in terms of UI permissions, you either have permission to the entire operation or you don't.
While using Kentico's back end UI would be beneficial, and giving them an account with limited administrative roles I think would be fine, what i would do is create a custom User interface and give them access to that UI, and all that UI element would be would be a drop down of available users to assign to the role, and a button that would use Kentico's API to assign them.
You can make the entire thing using the Custom Control webpart and point to your ascx, don't need anything particularly fancy.
the API to assign the role is pretty simple:
UserRoleInfoProvider.AddUserToRole(ValidationHelper.GetInteger(ddlAvailableUsers.SelectedValue, 0), RoleInfoProvider.GetRole("ContractorDownload").RoleID);
Make the drop down a list of (UserID, UserFullName) using the following dataset:
int[] UserIDsInContractorRole = UserRoleInfoProvider.GetUserRoles()
.WhereEquals("RoleID", RoleInfoProvider.GetRole("Contractor").RoleID)
.Select(x => x.UserID).ToArray();
int[] UserIDsAlreadyAssigned = UserRoleInfoProvider.GetUserRoles()
.WhereEquals("RoleID", RoleInfoProvider.GetRole("ContractorDownload").RoleID)
.Select(x => x.UserID).ToArray();
ddlAvailableUsers.DataSource = UserInfoProvider.GetUsers().WhereIn("UserID", UserIDsInContractorRole).WhereNotIn("UserID", UserIDsAlreadyAssigned).Columns("UserID, FullName").OrderBy("FullName").Result;
ddlAvailableUsers.DataValueField = "UserID";
ddlAvailableUsers.DataTextField = "FullName";
ddlAvailableUsers.DataBind();
Context:
I have recently been given the role as Azure Devops administrator in the small company I work in. I have no previous experience with this role, and I am currently reading through the extensive documentation on the topic.
What I've got:
An azure organization with several users, groups, permissions, and projects, some of which are up to 6-7 years old. Responsibility for the organization has been passed along several times without any clear plan or consequence, and I am attempting to get an overview and clean up the structure.
What I want to do:
I want to grant all users in the entire organization permission to read, comment on, tag people, and create new work items in Boards (especially backlog and sprint) in all projects, including the ones they are not a team member or user of themselves. I have tried several permission group setups, but I can't get anything to work. Suggestions are welcome.
Sorry but I'm afraid we don't support this feature.
We can't do this if the user is not a member of the project. (Unless he's a PCA, but it's not recommended to grant users as a PCA cause it'll make much risk).
So you need to add all users to projects first to give their permisions to boards. Here are detailed steps.
Create a new group Group1 in Organization Settings -> Security/Permissions. Add all users in the organization to this group.
Go to Project Settings -> General/Permissions and create a new group Group2. Set the Group1 as members of Group2.
Go to Project Settings -> Boards/Project configuration -> Areas. Choose the ... context menu for the node you want to manage and select Security.
Search Group2 and set 'Edit work items in this node' to Allow. Note that some important permissions should be set to Deny.
This solution needs you to add groups and set permissions in projects one by one.
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.
Hi i have a group system and i'd like to add some security to it.
Users can belong to multiple groups and id like to know the best way to authorize people to see the groups only if they are in it. If they aren't i want to redirect them to a another page, which is different according to the group.
For now i created a service but i have to use it in every controller...
I've heard of multiple things but not sure if they are appropriate for my situation.
Thanks for your help
There are several different ways to do this depending on the approach/complexity. Here are a few:
1) Use Symfony ACLS. When a user is added to a particular group, you can use the symfony ACL system to grant them view access to that group, and then later check isGranted() against that group to see if they have view permissions.
2) Create a custom voter
http://symfony.com/doc/current/cookbook/security/voters.html#creating-a-custom-voter
3) If the number of groups is limited in number, you could even use Doctrine query filters to automatically add a where clause to all queries where the group_id is in a list of allowed groups for that user. You can bypass this for all admin users. http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html
What I need is:
Administrator-level-1 (Can edit all simple users and administrators of level 2 and 3)
Administrator-level-2 (Can edit all simple users and administrators of level 3)
Administrator-level-3 (even less permissions)
By saying edit I mean change password at least. Tried to experiment with roles, permissions, Organization hierarchy etc. Is this possible?
You could create an Organization for each level and then can create a single Organization Role with the following permissions:
User / Update
Organization / Manage Users
Organization / View
Once that is done you assign the level admins to this role on the corresponding organizations.