Skip to main content
S
ShaylynJoy1-Visitor
1-Visitor
May 18, 2011
Question

Using Roles

  • May 18, 2011
  • 12 replies
  • 4009 views


Hi All,


We are currently using custom groups mapped to ACLs for permission control. We are interested in using the OOTB roles feature and are wondering what the benefits are to using groups versus roles.


Would anyone be willing to share their experiences?


Thank you,


- Shaylyn



12 replies

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
May 18, 2011
I studied and played with this in detail some time back but couldn't see the advantage. Still interested in understanding it.
D
ddemay1-Visitor
1-Visitor
May 18, 2011

Well you have to be willing to define new roles for specific use cases.

Too often admins only use OOTB roles and do not leverage them for profiles, filtering, ACL's.

If I knew what you were thinking about trying to specifically do I could probably comment better. I have found deny to work better with roles vs groups, etc.

I use four or five roles these days just for designers. Electrical vs. Mechanical vs. Software.




Sent from my Verizon Wireless BlackBerry
S
Selva1-Visitor
1-Visitor
May 18, 2011

I use to find no difference between Roles and Groups. Both are looking same and I am not sure if we can access Groups at Application container Level ( I assume that it is used at Org level only)


We found lot of issues with the ACL setting at Application container level (we had 20-30 Roles, I guess lot of)..Please dont use OOTB Roles ( I am afraid of using it).


I read somehwere in the PTC guide that, ACLs should be defined at Org/Site Level for better maintenance/easy management.


Still trying to find the difference between Roles,Groups, Profiles and Team (huuh)....



best of luck

S
SteveVinyard1-Visitor
1-Visitor
May 18, 2011
Roles –Context Specific Access control

Groups – Not Context Specific


Typically assign all ACL’s to the various roles at Context Level or Org level. Fill the various roles with appropriate groups to grant access. This allows a certain level of access for a group in one context while giving that same group a completely different level of access in a different context.

Now there are many ideas concerning ACL’s and Role definitions. I prefer to make them as flexible as possible to allow for future growth and needs. This typically consists of NOT defining specific Company roles but instead access level roles. For the specific Company levels Roles (I.e Manager, ECO reviewer) I may add them in but only for workflow needs.

The other access control roles are usually something like the following:

CAD Authors – can author and edit CAD, BOM and Docs
BOM Authors – Can author BOM and Docs and view CAD
Doc Authors – Can author Docs and view CAD and BOMs
Read-only – read everything
Read-Only at Released – read only released objects

I’m sure we could argue weeks about different use cases which means there is no set rule. I can certainly tell you to avoid using the delete rule though. If you have an issue simply remove the ability that has been granted to them earlier (team members).

On a side note, if a group gets deleted, all the ACL’s across all contexts get deleted as well.


[cid:image001.gif@01CC1548.EE428FF0]

Steve Vinyard
Application Engineer
D
ddemay1-Visitor
1-Visitor
May 18, 2011
Roles are not context specific, they are only holders to ensure consistent
behavior in ACL terms. The main difference between a Role and Group for an
ACL is the calculated value at runtime. Whereas you say they are context
specific you are referring to the calculated value in a container/context
team when they have been converted to a hidden/implicit wtgroup. At an ACL
level, everything is a group. Groups used in ACL's are solid and do not
change whereas Roles rely on what is using them to provide the principals
applicable.



It is best to assign them at an Org or at Site level. I do agree and I
was sort of saying the same thing, creates roles based on their access
needed. I typically will not create one role, grant the users privileges
to do everything to the one role and instead cascade the permissions per
role and add the principals to the desired roles to give them their full
required access. This was one way I got everyone on context/containers to
not use the Guest role and Members role. I personally hate both of those
roles.



I recently wrote my own load file importer for ACL based on Roles because
the OOTB breaks now that Roles are architected differently i.e.
WTRolePrincipal which extends WTGroup but has no LDAP distinguished name
(dn). I got to spend quite a lot of hours reverse engineering how all this
actually works to build my loader. I also learned how to delete existing
ACL's using load files which is not supported OOTB either. Haven't decided
if I'm going to give these bits away free yet.



Profiles vs. ACL's is usually quite clear. Profiles block access to
actions, but if someone with access emails a URL in Windchill to someone who
is missing the action but is granted permission via an ACL, they can still
view whatever that URL provides them access to.



Hope this helps,



David DeMay








H
HugoHermans12-Amethyst
12-Amethyst
May 19, 2011
Thank you Steve and David for your contribution. Could one conclude
that access controle rules are best defined on domains "/Default/PDM"
for PDMLink, or "/Default/Project" for ProjectLink, and adding Groupes
to Context Roles provide a means to make these rules context specific?

As an example, I create an "Engineering" role, added this role to most
of the libraries and products, added some ACL's in the /Default/PDM
domain for this role, and finally, and added specific groups of users to
the engineering role in each individual context. This way, the security
implementation of the contexts is transparant of the users.

An additional question, a poll actually, who is using the member and or
the guest role? What's the use case for the guest role?

Met vriendelijke groeten, Best Regards, Hugo.

NV Michel Van de Wiele
Carpet and Velvet weaving machines
M. Vandewielestraat 7
8510 Marke, Belgium
R
RussPratt8-Gravel
8-Gravel
May 19, 2011

Good question, and interesting responses. It is obvious to me that most admins don't really understand the fundamental business rule differences between the use of Groups and the use of Roles. Roles provide much more business flexibility, not the least of which is that Role participation can be managed at the application context level, rather than at the site/org context levels. What I find, and see confirmed here, is that generally the desire of the admin to simply his/her work, the business solution is constrained and limited by a missapplied use of Groups where the core system functionality is designed to use Roles.


That said, there are a couple of features that can be leveraged to get the best of both worlds. One is the use of Shared Teams, the other, and actually more powerful mechanism is to leverage the wtRolePrincipal object (unfortunately not yet well documented).


The gist of the RolePrincipal object is that you can write ACL policy rules for this role at the org context level, and those rules will automatically be inherited by any lower level Context Team Role that has exactly the same name as the RolePrincipal. Net result: I can manage Context Team membership at the context level, but manage the ACL's for all those roles at the Org level.


Unfortunately the "right" answer generally depends on specific business requirements, so I'm not going to attempt to just post a list of recommendations. But I should caution that the use of groups rather than roles to manage all business rules has shown in many cases to be a non-scalable solution in a large complex environment. Yes, it might allow all ACL management at the Org level, but that perceived advantage evaporates with large numbers of groups being created to handle every desired variation in the specific set of permissions that need to be applied.


One specific note as you begin to investigate Roles: ROLES ARE GENERALLY NOT JOB TITLES - Roles reflect responsibilties, not titles, don't confuse the two.


Russ

B
BrianSullivan10-Marble
10-Marble
May 19, 2011

I would agree with Russ limitation with Groups on future expansion.

The Key Idea Russ mention about Roles not being Job Titles is very important...
Groups are usually similar people while ACLs set against Roles are really a collection of Access Rights that grant you privileges.

For Example
CAD_Creators_Heavy : Could be a Role that you assign a groups of CAD Authors to that can Check in, Promote, Rename, Move
CAD_Creators_Light: Could be a Role that can only Check in when a CAD File is at its first State (such as Inwork)

In some products a group of users could be placed in the heavy; While at the products managed by a sister division or department they may be only in the Creators Light role.

Important to think about placing at the Context Level instead of the Org/Site Level is Generally You have Libraries where you do not want any of these groups to have Check In Rights to...
Think a Library with Pro/E Formats;
In that Library ALL Groups may be in a Role called CAD_Creators_Download_Only. Only the Admin or Librarian may be in the Heavy Role.

If you set Org Level Access Controls, it can lead to even more complicated access controls... When you need to add a Black Ops or a Special Concept Product for R&D Products... with Org Level Group Access... you would then start to Require additional DENY ROLES at the R&D Context Level....

As Russ says and those before, it really is based on your company whether you can have very simple access controls at Org Level or need to bring down to Context Level as I suggested above.

I think what most are saying is to keep your system flexible by not limiting your options... A little more setup time up front gives greater transparency and easier modification two years down the road when these topics may not be so fresh.

Brian Sullivan

PS
Remember to NOT make Roles from the Web Interface as a general rule, log onto the Server and create using enumCustomize..... That way if you ever desire to use OR need to use one of your Access Control Team Roles in a Workflow they can be used and will resolve the names properly to context team members.


P
ptc-52484391-Visitor
1-Visitor
May 19, 2011
A couple of comments / questions about your post:
B
BrianSullivan10-Marble
10-Marble
May 19, 2011
Michael,

It is Customer Dependent and I have Implemented at customers as you have suggested. With the Universal Roles. My example is not so much the Black Op Example as much as multiple Departments who need to slow tweak their context overtime and a preference not to use deny provilieges. But the Method you mention does minimize changes for universal changes which is its greatest plus...

But it can also lead to parallel Roles for the Divisions at the Org Level if divisions/departments can not agree on common acls.... Or as you noted specialized ACLs at the Context with (Additions and Denials)

I see more cases with slightly different access controls per context (and I promote additive acls versus use of denies) but divisions that want to use a Common ECN Process with a Common Workflow... which means a Common Role for all context really should exist between context (for easier workflow development)

I think we all agree the key is for Administrators to be aware of ALL the Techniques, Folder-Level Domains, Context Domains, Org Level, Use of Principal Groups so they can Chose best for their Company...

Brian

PTC Workflow Literature (Business Admin Classes, etc..) denote that a Workflow will not Resolve Team Administration to a Workflow Context Team unless the Role used in the workflow is a Resource Bundle Role. (ie made on server and Windchill fully aware of it) as compared to the Roles made in the GUI (Which just makes an LDAP Group).
Show more replies
Terms & ConditionsCookie settingsAccessibility statement