Skip to main content
D
Dobrisa1-Visitor
1-Visitor
April 5, 2018
Question

Group vs Role access controls

  • April 5, 2018
  • 2 replies
  • 7100 views

Can someone help explain differences between groups and roles in terms of precedence in access control policy? 

From the help documentation it says "Each role that is defined in a context team or team template has a corresponding system group automatically created with the same name." So Role Change Admin II is CHANGE ADMINISTRATOR II system group. 

Does this mean that roles and groups are treated interchangeably when it comes to access controls? In other words, if I assign Role "+Read" and then assign the corresponding System group "-Read", which one wins out?

 

 

2 replies

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
April 5, 2018

This is a very important area and worth taking some time to carefully both study and play with.

 

Create some test data and exercise "Edit Access Control" to observe what various Roles and individual users can do, drilling down to the policy statements responsible.

 

There is no right answer but many choices on how to approach this - all with pro's and con's.  Over 15 years I've gradually moved toward:

- Delete all ACL's that can be common to multiple Products/Libraries from a test Product/Library and save this result in Product/Library templates

- Create these ACLs at Org level, assigning most to Roles rather than Groups (e.g. assign Revise permission to the Designer Role)

- Map Groups to Roles in each Context (with special consideration for Shared Teams when possible); e.g. assign the Designers (plural) Group to the Designer Role in each context.

- Map Orgl-level Profiles (not license profiles) to Groups

- Assign each user to one or more Groups as needed (more to consider on this).

 

it's a really good multi-dimensional puzzle 🙂

 

You

D
Dobrisa1-VisitorAuthor
1-Visitor
April 5, 2018

Our concern at the moment is with external suppliers that are now starting to have access to our Windchill environment. 

The working theory has been that we'll assign them to groups and then manage access for them as a group. Playing with it initially, though, we found that we could inadvertently expose access to much more information than necessary (which is problematic for us). So right now, we're on the assumption that groups will not work for this since they haven't. So instead we're assigning individual access... and that's becoming an administrative nightmare. 

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
April 5, 2018

Ah - more very important info.  A major, major gotcha to be aware of is the pseudo-role "teammembers" which includes all Roles except Manager and Guest.  One can set up extensive elegant permissions schemes with other roles and have things not behave as expected because of this.  Try in test product/library deleting all ACL's for teammembers.

 

Also, very worth creating some test data (one at each state in the lifecycle) permanently in the system specifically to test permissions.

 

Also, create an org-level Profile and assign it to a parent group that all external users go into.  Uncheck EVERYTHING for the actions that you don't want exposed to these users. 

D
DanHarlan11-Visitor
1-Visitor
April 12, 2018

The first thing to understand here is what the documentation is talking about *G*

 

Their is only one type of Role, so that easy. But, "Groups" can refer to different things (and the documentation never distinguishes which is being talked about!). First their are "principal Groups" (my name) these are the groups created in the principal administrator inside Windchill and contain users and other groups. Second their are "LDAP groups" (again, my name) that you only see inside WindchillDS and the documentation reference above is actually talking about this type of group 🙂

 

So, if you ever compare your list of enumerated roles with your WindchillDS, you will see LDAP groups will that same names (except capitalized) in the there. (This is because LDAPs only have Users and Groups, they have no corresponding "role" entity for Windchill to use.

 

In terms of precedence, their is no difference between an ACL applied to a principal group or an ACL applied to a role, because in the LDAP, they at the same. Precedence (or hierarchy) of ACLs are based upon Deny/Grant/Absolute Deny.

- Grant overrides Deny

- Absolute Deny overrides Grant

 

Best Practice is not to apply ACL's to principal Groups, only apply them to Roles. Here's an example of why:

I have two products; "Product Designs" and "Product Brochures"

I have two groups; "Engineering" and "Marketing"

I have two roles; "Author" and "Viewer". Author has the ability to view, download, create, and modify content while Viewer can only view and download Released data. These ACLs are setup in the Org level PDM domain (so they are common to all products and libraries).

In the context team for Product Designs, the Author role is populated with the group Engineering and the Viewer role is populated with the group Marketing.

In the context team for Product Brochures, the author role is populated with the group Marketing and the Viewer Role is populated with the group Engineering.

 

Now, I've only had to setup two sets of ACLS (cause the policy administrator sucks!). Both contexts have different behaviors. When some joins or leaves one of the groups (new employee etc) all I have to do is add that person to the organization level group. Easy.

Terms & ConditionsCookie settingsAccessibility statement