Group vs Role access controls

[Dobrisa]

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?

[MikeLockwood]

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

[Dobrisa]

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. 

[MikeLockwood]

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. 

[STEVEG]

What I don't understand is how you are actually assigning access to a Role.  When I change to the Roles tab there are only 22 entries.  And one of them is the Organization Role: <Company Name>

There are many more roles that that.  How do I get the rest of them to show?

[MikeLockwood]

Each Role is "Visible" or not.  OTB, only certain Roles are visible.  Need to go to Org, Roles and make all that you want to use visible.  Also - This ties in closely with the context Teams (not same as Team Instances which exist for each object as it is created via OIR mapping).

[STEVEG]

The problem is 131 are visible in the Org > Roles area but only 22 Roles show up.  So why doesn't the rest show up?

[ChrisPLM]

Good question Steve

Now I recall we had created a special role. Maybe it was in those hidden ones ?

It was called  Global Design Support 🙂

Anyway. I cannot be of more help now.

Have a good day

[DanHarlan1]

Show up where?

Did you notice in the org level Roles list there is the ability to show and hide roles? Also, at the product/library/project/program level you can show and remove roles from the Context Team list.

Note, you also have the ability to create custom roles by just typing in a name NEVER DO THIS! Always enumerate your roles so they are available in all role lists. Those not enumerated are not available in all role lists (i.e. workflows, etc)

[STEVEG]

Hi Dan.  Yes.  There are 131 Roles that are marked as Visible.  But when I go to Policy Administration only 22.

[ChrisPLM]

Good morning/Afternoon

During my first implementation our external consultants created usergroups and assigned the ACL to them.

It was OK and I did not know any better. However the usergroups names ended up really looking like role with usergroups such as Design Engineers, Production Engineers etc...   As Windchill got deployed to new sites, that original structured developed for the first sites was no longer consistent. By then I have learnt a lot more about Windchill and as we developed a product centric organisation. ie regardless of the geographic location, we talked about the Team in charge of the product and that included people from different department and locations. So we then adopted the Team in the product context and also standardized by creating product template.

The drawback was that if you have a group of people (let's call them a Global Design Team) who have access across different product contexts, then each product team needed to be updated individually instead of updating a usergroup that is used across multiple product contexts.

At the end, we ended having a mix of both. Some users where only in Roles, while others were in usergroups and the usergroups put in the corresponding roles.

Best regards

[DanHarlan1]

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.