-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
3
-
0
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
We manage all of our permissions in Active Directory via permissions groups that follow a strict naming convention to specify space permissions. For example:
- TOOL_Confluence_Main_Admin: This group has Admin permissions in the "Main" space.
- TOOL_Confluence_Main_Edit: This group has edit permissions in the "Main" space
- TOOL_Confluence_Main_Comment: This group has comment permissions in the "Main" space
- TOOL_Confluence_Main_View: This group has view-only permissions in the "Main" space
The idea is that all permissions are managed in Active Directory, and it is very easy to see exactly who has permissions in which Confluence spaces, and what level of permissions they have - both inside AD and inside Confluence.
We have trained all the Confluence System Administrators to set permissions up this way when a new space is created - and only system admins are allowed to create site level spaces. The problem is, there is no reasonable way to restrict the management of permissions to ONLY Confluence System Administrators.
We could make it so that ONLY Confluence System Administrators have "Admin" permissions in all spaces. The problem with this option is that teams and departments then have no way of doing the other space administration tasks that we would like to allow them to do such as customizing their sidebars.
Security is the other important factor here. It is important that only trained administrators manage permissions because untrained users may grant permissions to groups that are too broad and include external contractors that should only have limited access to spaces on an as-needed basis.
My request is as follows:
(1) Add a "Permissions" checkbox on the space permissions page - or modify the exiting "restrictions" checkbox to also apply to permissions.
(2) Make it so that if "Permissions" or "Restrictions" is unchecked then the user cannot manage permissions or restrictions - even if the "Admin" box is checked. Currently, with the Admin box checked, a Space Administrator can manage restrictions, even if the "Restrictions" box is not checked.
- is cloned from
-
- Closed
- relates to
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-37088] Separate permissions management from space administration
Our organization would like to provide all admin privileges to space administrators EXCEPT the ability to add and remove users / groups. We have to be able to attest to all access granted in all systems, and to do so we use external tools and, for the most part, Active Directory groups. We'd like to be able to have users request access, have that access approved by the space administrator, then added to the appropriate AD group that controls access to the space. That way we can demonstrate to auditors that the access was granted in the proper order and approved by the appropriate personnel.
We are in exactly the same boat as the OP. We don't want the role we have defined as "Space Managers" to have Admin permission on spaces because we have carefully crafted and named groups with defined permissions. Their permissions are configured when a space is created and are not subject to change at the whim of the functional manager who has responsibility for the content within the space. This is the only way we can confidently maintain assurances of the principle of least privilege in our role-based access control model. Just like the ability to manage restrictions is a separate permission from general space administration, so should be the ability to manage permissions.
The specific situation in which we discovered this problem is that people in our space manager role can delete pages but can't restore them from the Trash because they don't have Admin permission. I would prefer to see separate permissions for admin and permission management rather than a separate permission for "Restore/Purge Trash", however, because I think the permission management issue is a more general and widespread one with far greater security implications.
Julian Heeb
added a comment - We are also looking forward to see this feature implementend. As the reporter we would like to manage space permissions via Active Directory exclusively.
However I would suggest not to merge a "permission" and the existing "restriction" checkbox. It should for authorized users still be possible to restrict pages even if they are not authorized to grant permissions to a space.
Julian Heeb
added a comment - We are also looking forward to see this feature implementend. As the reporter we would like to manage space permissions via Active Directory exclusively.
However I would suggest not to merge a "permission" and the existing "restriction" checkbox. It should for authorized users still be possible to restrict pages even if they are not authorized to grant permissions to a space. +1 as well. Segmenting out Space Administration from Space Permission management would be great. From a SOAP-API (and presumably REST when it can manage perms) standpoint:
ADMINSPACE - Administrative access to the the site except for modifying site permissions
SETSPACEPERMISSIONS - Allow modification of access to the site
So the combination of ADMINSPACE + SETSPACEPERMISSIONS would be what today is just "SETSPACEPERMISSIONS".
Would also allow for something like Help Desk users to be able to modify access to sites without having full access to the site content.
Wolfgang Fellner
added a comment - +1
We need to restrict Space Admin from adding users and groups to spaces for CUI access control. Thank you.