Security Model

[HugoHermans]

Is someone willing to share some thoughts about a conceptual security model?

I'm rethinking the way I try to organise the access control rules, in order to prepare a migration from 8.0 to 9.1. Windchill 9.1 has new permissions, has the ability to use context team roles on organisation level, allows to change permissions ad hocfor anobject, and most of all, the security rules I actually implemented aren't full proof.

The security model I'm working on spans ingeneral the objects EPMDocuments, WTDocuments, WTParts and Change objects. Without going into detail, the general profiles I can think of are (1) someone that can read released data, (3) someone that can read all data, and (3) someone that can create and modify (according the life cycle state).

One of my issues is whether or not to provide a context role for every combination of a 'general profile' and 'general objects'. I will end up with at least 12 roles of each container, disregarding workflow driven roles, what's a little bit rediculous. But will it be feasable over time to maintain roles for several combinations of profiles and objects? Or is it an exercise in balance between flexibility and maintainability?

TIA, Hugo.

<< ProE WF3 M190 - PDMLink 8.00 M040 >>

[sauls]

Herman,

From my experience implementing 9.1 Access Control Rules, i sugget you to
implement a kind of "Access Control Levels", i mean to specify
(conceptually) let's say 3 groups of permisions for each product: Level 1,
Level 2 and Level 3.

Level 1 should have only Read and Download Access
Level 2 Modify and create for In Work
Level 3 Administrative privileges

Then implement it by setting the rules of the OOTB Guest, Member and Product
Manager (At the Product Context, if you have too many products, then switch
to SharedTeams)
And adding Organization context groups to those roles, and the relevant
users to those groups.

If you need additional access control levels then you can try adding it, but
avoid as much as possible defining new roles, don't forget that guest,
members and Product Managers have hardcoded behavior defined in windchill
code.

Saul

On Mon, Feb 15, 2010 at 10:53 AM, Hugo Hermans
<->wrote:

> Is someone willing to share some thoughts about a conceptual security
> model?
>
> I'm rethinking the way I try to organise the access control rules, in order
> to prepare a migration from 8.0 to 9.1. Windchill 9.1 has new permissions,
> has the ability to use context team roles on organisation level, allows to
> change permissions ad hoc for an object, and most of all, the security rules
> I actually implemented aren't full proof.
>
> The security model I'm working on spans in general the objects
> EPMDocuments, WTDocuments, WTParts and Change objects. Without going into
> detail, the general profiles I can think of are (1) someone that can read
> released data, (3) someone that can read all data, and (3) someone that can
> create and modify (according the life cycle state).
>
> One of my issues is whether or not to provide a context role for every
> combination of a 'general profile' and 'general objects'. I will end up
> with at least 12 roles of each container, disregarding workflow driven
> roles, what's a little bit rediculous. But will it be feasable over time to
> maintain roles for several combinations of profiles and objects? Or is it
> an exercise in balance between flexibility and maintainability?
>
> TIA, Hugo.
>
> << ProE WF3 M190 - PDMLink 8.00 M040 >>
>
>

[HugoHermans]

Hi Saul,



Thank you for your reply. The lesson is to keep it simple and
straightforward, isn't it?



The roles I generally have, are :

- designer/engineering :

o are the authors of EPMdocuments , can modify these objects 'in
work', can revise and promote

o can create and modify change objects

- design team leader :

o not sure about this one (should he get less or more access
rights??)

o can create and modify change objects

- member :

o are the authors of WTDocuments, can modify these objects 'in
work', can revise and promote

- industrialization :

o can read what the authors made, disregarding life cycle state

- restricted/confirmed :

o can only read 'released' objects

- public :

o not sure about this one either

- guest :

o not used at the moment



What I learned about Windchill 9.1

- 'Shared Teams' can only be setup during the creation process
of a container (?)

- On the organization level, there is no context group for
Member (is this because it is hardcoded?)



Some extra remarks :

- I configured the 'Delete' access on life cycle level, to
restrict the delete action to the creator of the object (as long as the
object is in work).



Kindest regards,

Met vriendelijke groeten,



Hugo Hermans



-

[sauls]

Hi Herman,

Yes indeed, try to keep it as simple as possible.

If you analyze your access control requirements you probaly will reach the
conclusion that you need less groups that you originally thought you will.

But in Windchill the Access Control rules for members and guests appears
only at Product context level, not at organization.

So the solution for that is either to use Shared Teams or to include those
rules in the product template you use.

Also keep in mind that if you belongs to any role within a context team
(besides guest) you atomatically become a member andreceive all the member
permisions, so if you want to give someone permision only to read released
objects you should either modify defaut guest permisions or keep the user
out of the context team, granting permision to read released objects at the
organization level.

Also keep in mind that (even in Windchill 9.1) promote action requires
modify permision.
You also are right, Shared Teams can only be set during product creation,
there is no way to transform an existing product to use a shared team or to
delete the shared team definition once created.

If you want to transform a regular product (as migrated from Windchill 😎 to
one which uses shared teams, you should create an empty product with shared
team and then move the contents (it is not so difficult since you can move a
folder from product to product and it will take all its contents with it)
from the original product.

Try to avoid using Advanced life cycles, use as much as possible Basic.
Best Regards

Saul

On Mon, Feb 15, 2010 at 2:08 PM, Hermans Hugo
<->wrote:

> Hi Saul,
>
>
>
> Thank you for your reply. The lesson is to keep it simple and
> straightforward, isn’t it?
>
>
>
> The roles I generally have, are :
>
> - designer/engineering :
>
> o are the authors of EPMdocuments , can modify these objects ‘in
> work’, can revise and promote
>
> o can create and modify change objects
>
> - design team leader :
>
> o not sure about this one (should he get less or more access
> rights??)
>
> o can create and modify change objects
>
> - member :
>
> o are the authors of WTDocuments, can modify these objects ‘in
> work’, can revise and promote
>
> - industrialization :
>
> o can read what the authors made, disregarding life cycle state
>
> - restricted/confirmed :
>
> o can only read ‘released’ objects
>
> - public :
>
> o not sure about this one either
>
> - guest :
>
> o not used at the moment
>
>
>
> What I learned about Windchill 9.1
>
> - ‘Shared Teams’ can only be setup during the creation process of
> a container (?)
>
> - On the organization level, there is no context group for Member
> (is this because it is hardcoded?)
>
>
>
> Some extra remarks :
>
> - I configured the ‘Delete’ access on life cycle level, to
> restrict the delete action to the creator of the object (as long as the
> object is in work).
>
>
>
> Kindest regards,
>
> Met vriendelijke groeten,
>
>
>
> Hugo Hermans
>
>
>
> -

[sdrzewiczewski]

You can set a preference to disable this behavior. It’s under the Promotion options.