I would be happy to get some advice on "workflow" type. Im not sure what is best - "Intranet/Extranet", "Simple Publication" or a third choice. Below are the types of folders and roles Im looking for:
public folders: anonymous has "r".
intranet folders: users has "r". Special users has "rw".
private folders: only user in question and admin has "rw" (special users has also "rw")
special folder: users that are member of a group has "rw".
Lastly, I do not understand this, users with e.g. "read", "edit" or "contribute" role can see user folders (marked as private), but also a test folder created as admin (marked as private)? PS Im using "Intranet/Extranet" type.
Thanks.
Nikolaj G.
You're confusing Roles and Permissions in your question. "read" and "write" would be permissions. Reader, Editor, Contributor are Roles.
In an Internet/Extranet workflow, Anonymous users (a Role) would get Read access to Public content.
Private content would be accessible to users with the Owner or Manager (Administrator) role
"Internally Published" content is readable by users with Contributor, Editor, Manager, Member, Owner and Reader roles, but only editable by Managers.
"Internal" would correspond to the "Intranet" setting you want - where most users get read access, but you can give users the "Editor" role (using the sharing tab) to allow them to modify content.
Your "special" folders would simply be in the "Internal" state, but you would grant the Editor role to a group rather than a user.
Your last paragraph doesn't make much sense. What do you mean by "created as admin"? Created by admin?
In the Internet/Extranet workflow, the only difference between Private and Internal states is that "Members" can not view private content - but Editors can modify it and Contributors can view it.
Go to /portal_workflow/intranet_workflow/states/manage_main in your site to see the various Role-to-permission mappings
Related
My organization has some domain wide calendar resources (to depict meeting rooms). I need to be able to edit the resource's calendar. What permissions would I need for it?
A reference (under heading - Permission Settings) on Google Workspace Admin says that with Make changes to events privilege, users can see event details and modify any event, but the option is available only when the resource is shared with specific people, not the entire organization.
So, if the resource is shared with whole organization I have no choice. But isn't there some admin role (except super admin) or privilege that can enable me to edit domain wide resources?
I understand that your organization has one particular resource, whose calendar has some events that you want to edit. In that case in particular the resource is shared with the entire organization. If that is correct then, as you accurately pointed out, only the superadmin can edit that calendar events. As an alternative you could create a service account with edit privileges over the resources and grant it domain-wide delegation to edit those events as if the superadmin were doing so. Then you could use that service account to call the Calendar API as needed, per example the Events.update method.
I have a user with permissions across many projects (see image below).
I have a new user who just joined the company. I want to give him the exact same permissions. How can I do this? I don't want to do it manually because that will take me ages and the Google Cloud Documentation is useless! I cant find much on using gcloud command line to do this with examples.
There must be a easy way to duplicate permission?
Thanks
It is indeed possible to grant a role to a member for more than one project:
Open the IAM & Admin Projects page in the GCP Console.
Select all the projects for which you want to grant permissions.
Click the Show Info Panel, followed by the Permissions tab.
Enter an email address in the Add members field, and select the desired role from the drop-down menu.
Click the Add button. The member will be granted the selected role in each of the selected projects.
Granting access rights to project is an action fraught with security risks, so bulk gcloud commands or simple copying of roles are understandably not supported.
You can find more detail on the "Granting, Changing, and Revoking Access to Resources" documentation page.
I am working with a lot of MODX since 2010. From time to time i coudl need another user group with restricted permissions. Like "Can edit content, but not change settings". So the user can't break anything which is relevant for die CMS itself.
I added users, placed them into roles and groups, but somehow it never works the way I expect it to work. A role is not a "role" but a level of authority. A group is just a link to a set of permissions, which is already setup as a ruleset. Still, if I create and setup the group "content editor", I never get it running as expected.
Is there a guide (or even an extra?) to setup restricted user account without breaking ones brain?
There's a basic tutorial available in the official documentation: https://docs.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/giving-a-user-manager-access
My personal recommendation would be to ignore roles altogether. Whenever you need to enter a role (when adding a policy to a user group, or when adding a user group to a user) just pick "Super User - 0". They're an added complexity to allow, essentially, different permissions within the same user group, that 99% of the people don't need.
The primary thing to do is to create a policy, based on the "Administrator" policy set, that contains the permissions you want the user to have in the manager. Those would include the relevant resource/document permissions, but not settings, for example.
Then you add that policy to the user group of your choice as a "mgr" context policy.
The usergroup will also need context permission to be able of interacting with specific contexts. So on the contexts tab in permissions, add the different contexts you want, with the contexts policy.
As #optimuscrime commented, ACLs can be a little complicated, but that's the general approach.
I am trying to model some complex permission management system using apache shiro.
English not being my native tongue I am afraid I might be missing some of the subtleties of terms such as "Roles", "Permissions", "Rights" & "privileges".
For example lets say I want to create a system that manages resources such as printers located inside buildings.
A DB holds the information of which printer is located in what building.
Users of that system should be able to reset a printer or print to it.
Its clear to me that some users will be "Super Admins" and be able to reset and print to any printer ('printer:*:*')- I guess that we could say that those people have a "Super Admin Role".
But what if someone should be allowed to reset the printers in a specific building ('building:A:*') ? Is "Building Admin" a (prarametric) role? or is this just a permission on a specific building? How would you model this using apache Shiro?
n.b.
When tagging this Q I added the user-roles tag and it says:"A user role is a group of users that share the same privileges or permissions on a system. Use this tag for questions about how user roles work in a particular security framework, or questions about the implementation of user roles in your program."
Would I be correct to assume that based on this definition there is not such role as a "Building Admin" because being an Admin of Building A does not give you the same permissions as does being an Admin of building B?
and if so, what would be the correct terminology to describe a "Building admin"?
Have you considered using more than three tokens within the WildCardPermission format?
There is no limit to the number of tokens that can be used, so it is up to your imagination in terms of ways that this could be used in your application.
— WildCardPermission Javadoc
Instead of the domain:action:instance syntax commonly used in Apache Shiro examples and documentation, you could add another token to represent the building, e.g. printer:print,reset:*:buildingA.
The downside of this scheme is that whenever you are checking if an action is permitted on a particular printer, you'd now also have to specify the location, even though the token representing the printer instance might already uniquely identify that printer:
// let's say the role for buildingA-admin has permission of "printer:*:*:buildingA"
subject.isPermitted("printer:print:epson123:buildingA"); // returns true
subject.isPermitted("printer:print:epson123"); // returns false
Depending on your application domain, maybe a structure like buildingA:printer:print,reset:epson123 might even be more appropriate or useful.
To answer your other question regarding user roles, you'd be correct to assume that if you have both buildingA-admin and buildingB-admin roles, they are different user roles, if the permissions assigned to them are not the same.
You might conceive a general user role of Building Admin for permissions that all admins for the different buildings might have in common, to avoid duplicating those permissions across the different building-specific admin roles.
I have to programmatically create a task for a user that was not explicitly added in the site users. He has permissions to contribute to the task list, though, because he belongs to an AD group that has been granted those permissions. I can assign the task to the user through the UI; how do I do it through code though?
The accepted way of assigning tasks to users is to set the AssignedTo field of the task to an SPFieldUserValue pointing to that user. Except it cannot be done in this case, because the users cannot be found in SharePoint, only his group! Assigning the task to the whole group is a bad idea, for obvious reasons. And our system administrators categorically refuse to add the users to Sharepoint one by one, because that would duplicate the data they have in Active Directory, and generally be a pain to manage. What do I do?
When a user authenticates to SharePoint, an entry is created for them in the profile store, even if their permission to the site comes from an AD group.
I did a quick test by adding new user (TGroupsUser) and group (SPtestPermissions) to my AD, so there is no chance the user was ever on my site before. I added the user to the group and gave the group "Member" permissions to my site. I then authenticated to SP with this new user.
To show that the user is part of this SPWeb, I wrote a quick webpart to enumerate the users on the web. Note that there are three groups of users with the SPWeb. All Users, Site Users and Users. See this link for full description of these properties. Basically, users are users on the web. Site Users are users and groups on the site collection. All Users is all users of the site including those granted direct permission or granted through group and then visited the site. Here are the results, minus the system accounts.
All Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Site Users
SPSDEV\rross
SPSDEV\sptestpermissions
SPSDEV\TGroupsUser
Users
SPSDEV\rross
Since this account (TgroupsUser) is part of the user collection for the web, you can treat just like a user added directly to the site. To finish the testing, I created a task with the following code for the assignedTo field.
TaskItem[SPBuiltInFieldId.AssignedTo] = web.SiteUsers.GetByEmail("myemail#domain.com");
Here is a screenshot of the new task assigned to TGroupsUser.
FYI - I needed to use AllowUnsafeUpdates on the web object.