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

Access Policy Administration Best Practices

HugoHermans
Bedrock

Access Policy Administration Best Practices

Introduction

A document ment to contain best practices on the configuration of access policies.  Since this is subject to personal appreciation, professional contexts, etc, it is highly likely that this document will contain contradicting opinions.  At least, when other authors add their concepts as well.

Concepts A

These concepts are based on my experience in Windchill 9.1 (Michel Van de Wiele), and input gathered from the PTC/User mailing list.

An important requirement is that the day-by-day users have to understand why they can or can't do or see things, and maybe even more important, that the management has an understanding of it.  So, the general concept should be straight forward and generic among containers.

The general idea is that objects are always to be considered as confidential, and that actions have to be allowed explicitly.

Domain selection

  • Try to configure as much as possible in the PDM domain.  This will not jeopardize your projects in ProjectLink, and is general enough to avoid repeating the rules in every product or library.
  • Avoid the default domain in the individual products and libraries.  During the migration from 8 to 9.1, a lot of rules were added to this domain, so it is likely that this will happen again in the future.
  • Specific rules are only added to subdomains of the product/library default domain (i.e. the second level).

Folders in products/libraries

  • Avoid to add anything to the root folder of your container.
  • Create subfolders according the object types (wtparts, wtdocuments, epmdocuments, ...).
  • Within these first level subfolders, objects are to be considered as confidential.  Further subfolders may broaden the accessibility.

Softtyping

  • Create a first level softtype, based on the department (Aftersales, R&D, Purchasing, ...).
  • Second level softtypes represent the general usage of the document (general, manual, instruction, meetingnote, ...).

Context Roles

  • Try to interprete and configure each role in each product/library always in the same way.  The Engineering/Designer is always the main author in the container, Guest only has read access to Released objects in the Public subfolder (as an example).

Access rules

  • Most of the rules are configured (once) on PDM-level, but this domain never ever should contain create-rules.  To reduce the number of rules, most of them in the PDM-domain are based on root type or first level softtypes, seldom on second level subtypes.  Since the interpretation of the context roles is generic amoung all containers, it is obvious to define these common rules for these roles.
  • As said, I never add rules to the default domain of a container.
  • In the first level of subdomains, you will find all necessary create-rules, based on second level objecttypes.
  • In the second level subdomains, I broaden the access rights.

General implementation (as an example)

  • Designer/Engineering has general read/write access to most objects in the container.
  • Industrialisation has general read-access, but no write access
  • Member has only read-access to Released objects, and read access to all objects in the Public folder
  • Guest has only read-access to Released objects in the Public subfolder.

Final Remarks

  • Shared teams seems to lack flexibilty.  They have to be present at the moment of container creation, and are hard to change afterwards.  Unless someone can shed some light on this, the concepts above disregard shared teams.
  • To ackomplish restricted access, assigning groups to container roles should be sufficient.  E.g. the library containing drawing formats, designers are assigned to the Members role.

Concepts B

... (to be completed)

Concepts C

... (to be completed)

4 REPLIES 4

Re: Access Policy Administration Best Practices

Hi HugoHermans,

 

Out of curiosity, is the rest of the Concept completed...???

At our organization, we are planning to clean up our existing Product Containers and Libraries.

 

Your feedback will be very valuable.

 

Regards,

PRKAC

Re: Access Policy Administration Best Practices

Hi,

 

That is ~10 years old ... 🙄 ... djeezes, time flyes.  But I will pick it up again, and let you know.

 

Hugo.

Re: Access Policy Administration Best Practices

Thanks alot HugoHermans:)

Re: Access Policy Administration Best Practices

@PRKAC I reread it, I think it's still the way I work.  Some comments:

- Concept B and Concept C were ment to be completed by someone else.  Apparently, no-one took the challenge.

- For Concept A, what should be added is the organisation of the ACL domains.  The top-most domain should be the most restricted one, child domains should only add grant permissions.  The reason is that a deny rule is difficult to overrule in a child domain.

- From the beginning, I only allow in rare cases the possibility to move objects from container/folder to container/folder.  This is because security is based on the folder were the object is located.  But this also helped me to educate my users not to use Windchill as they use Windows Folders.

Announcements