Where to create Access Control Rules? Context or Org?

[mdebower]

I am in the middle of creating some access control rules and have the following questions for everyone:

• What are your best practices and considerations when creating Access Control Rules? 
• At what level do you create them, context or org?
• What considerations do you make when creating them?

My first inclination is to create them as high up the structure as it makes sense.   In this particular case I want a set of rules for a custom role called ENG Admin.   Think of a Library Manager or Product Manager permissions but only for WTParts and CAD / EPM Docs.  Since it would seemingly apply to every Product and a lot of Libraries, my thought was to create it at the ORG level.

I look forward to seeing what the group comes up with.

-marc

CAD / PLM Systems Manager

TriMark Corporation, New Hampton, Iowa

[TomU]

At Mike Lockwood‌'s recommendation we have moved almost everything out of the context (and their related templates) and up to the ORG.  This makes it much easier to make system wide changes without having to make them inside every single product and library.

[mdebower]

Tom,

That was first thought too, but then I sabotaged my thinking by looking at the messed up way PTC did it...  

Mike is on the right track most of the time when it comes to Windchill, so I think I will follow his advice as well.

-marc

[MikeLockwood · Accepted solution]

I truly don't believe that anyone at PTC responsible for this stuff actually tries to administer a real system.  If they did, each would come to the conclusion within a day that all ACL's which are common to a group of Products and Libraries should be deleted from the them and brought to Org level.  Super laborious to make an agreed change one by one across 85 Products and 13 Libraries.

Note: Using "Private" for some contexts is also critical to make this work well (meaning avoid use of DENY like the plague).

- Examine all the ACL's resulting from creating a Product/Lib from the OTB templates.

- Decide which are common to many Products/Lib's; create these at Org, PDM and delete from Product/Lib; save result as new Product/Lib templates.

- By exception and with careful documentation, add some to individual Product/Lib

- For some contexts (esp. Lib's), make Private, which removes inheritance from Org/PDM and makes that context only use the ACL's in it.

- Try to start with 'no user can do anything and add each as needed (avoids DENY)

- Look carefully at the effect (many OTB) of the pseudo-role TeamMembers, which can wreak havoc unless you really understand what it's doing

- Have to think in 5 dimensions: to what (object type), when (at what state), who (principals), what can be done (permissions)

- Even with all this done superbly, you'll get completely messed up unless you null out the many "implies": properties that automatically select additional permissions when you select any (see my other rants on this one)

- Confirm all using Manage Security

- Best for Manage Security is to create objects (i.e. CAD Doc), one at each state in each representative Product/Lib and leave permanently, and then create some test users than can be used to confirm.

- Big decision to be made for every single ACL is to use a Group or a Role (context team role exposed at Org level).  Over time, I've moved almost all to the Role instead of directly to Groups.  This also facilitates use of Shared Teams where possible.

Don't mean to sound negative here - I actually truly love the puzzle of figuring out the most elegant and robust way to approach user permissions, with related groups, roles, etc.

[slapha]

I agree with Mike and Tom. We're just now going through and trying to untangle the mess of Product level access controls. We're also moving from Single-Org to Multi-Org which throws some other interesting wrenches in to the mix. If access is generally the same, Org level is the way to go. Shared teams also helps makes things easier to consolidate and control.

We limit our controls to essentially 3 "roles" not counting administrative access. Member, Guest, and Team Lead. Where Team lead only has the added ability to manage the team membership. We try to have no one in Product manager except administrative roles. Team roles (which are member by default) are then only used for workflows and as part of building a team roster.

The only way Product level access works is if each product manages themselves. Where product manager is basically a low-level Windchill admin like PTC hardcoded in the system. It is still not the best idea to have most of the ACL's defined at the product level. It could also work if you only have a handful of products and each one has unique requirements.

[BjoernRueegg]

We also recommend to create the ACL on Organization level. This makes the administration a lot easier, especially if you have multiple context.

The only disadvantage is, that it's not possible to load ACL from CSV to Org. So you need to create some xml files or create it manually within the policy manager.

My best experience is also not to use deny rules. It's better to create 10 rules for each state rather to create one for all states and deny some other states.

I've created an utility to export the ACL to Excel and import it from there again. This would be something PTC should provide OOTB since the creation of the ACL is a really pain (also in the new policy manager in 11.0).