cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

Source: disable access to subproject for all except special group

ssaul
15-Moonstone

Source: disable access to subproject for all except special group

Hello,

we would like to disable access (openproject, fetchrevision) to a subproject for all except a special group.

Example:

project_A

|- (sub)project_B

|- (sub)project_C

group_A and group_B have access to project_A and project_C.

Only group_B should have access to project_B.

Our first approach was to allow the permissions for project_A for both groups and simply deny the permissions for group_A in project_B.

The problem is that some users may be members of both groups and so the deny overrides the permission.

We thought this might be a common configuration management task and so this should be possible, so maybe we overlooked something?

Is there another solution?

ACCEPTED SOLUTION

Accepted Solutions
mrump
16-Pearl
(To:ssaul)

Hi Stephan,

at least for workaround you can allow the Access to Project_B explicitly for named users that are also members of group_A.

User principal ACL entries overrule the group principal entries, so you can explicitly grand access to a user although one of his groups is denied.

This worked fine for us during the last years, but it also means extra maintenance effort.

HTH:

Matthias

View solution in original post

6 REPLIES 6

Hi Stephan,

Essentially, this comes down to creating a group of all of the members of A who are not also members of B, and then denying that group permission. Based on your problem, I'm going to guess you are using Integrity 10.3 or later.

You might be interested in RFC 135701 (a feature request). In a nut shell, this feature request asks for the possibility to break the ACL inheritence chain on a project configuration, so that you could define permissions at that level "from scratch" at a given project/subproject level. Please contact Integrity Support to discuss this, and see whether it would be appropriate for your needs.

Regards,

Kael


Kind Regards,
Kael Lizak

Senior Technical Support Engineer
PTC Integrity Lifecycle Manager
ssaul
15-Moonstone
(To:KaelLizak)

Hi Kael,

thanks for your hints.

Yes, we are using Integrity 10.4.

Creating a group of all of the members of A who are not also members of B won't work really good if group_A is the everyone group. Even if not, we would always have to change the new group and group_A simultaneously.

The RFC sounds interesting - we asked support to be added to it.

Stephan

mrump
16-Pearl
(To:ssaul)

Hi Stephan,

at least for workaround you can allow the Access to Project_B explicitly for named users that are also members of group_A.

User principal ACL entries overrule the group principal entries, so you can explicitly grand access to a user although one of his groups is denied.

This worked fine for us during the last years, but it also means extra maintenance effort.

HTH:

Matthias

ssaul
15-Moonstone
(To:mrump)

While waiting for the (not very probable) implementation of the RFC, this seems to be the only working solution.

Thanks, Matthias!

Matthias' suggestion works best, if you have a small number of users who need access to Project_B. I've heard of two scripted approaches to this sort of issue: One is scripted group management, including a GUI built by one customer (not, to my knowledge involved with PTC Global Services), and the other involves what David Hegland suggests below to do this at a user level.

Any of these three methods works better than waiting for that RFC to be implemented, but I would still recommend posting your organization against the RFC, since indications of customer demand do have some influence on which features are implemented.

Regards,
Kael


Kind Regards,
Kael Lizak

Senior Technical Support Engineer
PTC Integrity Lifecycle Manager
dhegland
12-Amethyst
(To:ssaul)

Hi there. I like Matthias' suggestion. I've been using that approach for a couple years. To make it feasible I created a little script to spawn the personal ACLs from a group ACL. Here ya go.

param(
# --------------------------------------------
# create-personalacls
#
# This script is for use by PTC Integrity Admins.
# It is intended to work around group overlap when denies trump grants.
# Personal grants will trump group denies, which is why this script exists,
# to make it easier to manage personal ACLs without tedious manual effort.
#
# The script will create a personal ACL for each member of a given group.
# You must first create an ACL for the group, and this script will
# copy the permissions from that ACL into each user's personal ACL.
# --------------------------------------------
[String]$acl,
[String]$group
)
$acloption='--acl='+$acl
$users=aa.exe groups --members $group | select -skip 1 | foreach {$_.trim().split()[2]}
$permissions=aa.exe viewacl $acloption | findstr $group | foreach {$_.trim().split()[0]}

$users | foreach {
$u=$_
$permissions | foreach {
$entry='u='+$u+':'+$_
aa.exe addaclentry $acloption $entry
}
}

Announcements


Top Tags