Windchill Policy Administration within TEWI Administrative Domain

Transcription

1 JOURNAL OF APPLIED COMPUTER SCIENCE Vol. 21 No. 2 (2013), pp Windchill Policy Administration within TEWI Administrative Domain Konrad Swirski, Urszula Zajkowska Technical University of Warszawa Faculty of Power and Aeronautical Engineering Nowowiejska 21/25, Warszawa [email protected] Technical University of Białystok Institute of Computer Science Wiejska 45A, Białystok [email protected] Abstract. This paper covers some chosen aspects of policy acces management in Windchill system that are crucial from TEWI administration standpoint. This aspec is very important administrative activities for TEWI platform maintenance. Keywords: TEWI, PLM, Windchill, policy administration, access rights. 1. Introduction As an in integral component of ptc s product Development System, Windchill manages all product content and business processes throughout the product and service lifecycle. And it has a robust, high-performing architecture to help and to prepare for tomorrow s uncertainties. It s manage such information as manufacturing information, service information, part/supplier data, calculations and illustrations. Windchill can also play an important role in increasing a company s

2 154 Windchill Policy Administration within TEWI Administrative Domain competitiveness by allowing continuous improvements and automation of business processes and procedures. All these arguments confirm the validity use of Windchill as a base for TEWI projects. The most important things with large system is security of the system especially for military projects. The same mechanisms are used with small TEWI projects. 2. Management of access rights The first and the most important way to manage policy access is the concept of the Windchill Domains. There are several different domain types. The figure 1 captures perfectly the idea behind domain implementation in the Windchill system. Figure 1. Root is main domain and can therefore be used to set rules that govern the entire enterprise. Very important is System domain witch stores policies for administration type objects including queues and lifecycle definitions: LifeCycleTemplate WfTemplateObject WTTypeDefinition

3 K. Swirski, U. Zajkowska 155 WTPrincipal AccessPolicyRule Default domain is containing business objects such as: PDMLink Object Type Java Class All (parent of all objects) WTObject End Item WTPart subtype Parts WTPart CAD Documents EPMDocument Documents WTDocument Problem Reports WTChangeIssue Change Requests WTChangeRequest2 Change Notices WTChangeOrder2 Change Notice Tasks WTChangeActivity2 Managed Baselines ManagedBaseline Private domain stores policies for business objects in application containers that are set to private. SessionIteratedDomain serves as the default domain for internal session processes. User serves as the default domain for organization objects and as the parent domain for the Unaffiliated domain and for organization context domains that hold the users for that organization. The last one domain is Unaffiliated the default domain for users who are not associated with any organization. TEWI organization containers have the domains include: A User domain for user objects, created under the site-level User domain. A System domain that holds policies for administrative objects in that organization container. Default and Private Domains that hold policies for business objects in that organization container.

4 156 Windchill Policy Administration within TEWI Administrative Domain TEWI application Container Domains are System and Default that hold policies for administrative and business objects respectively. The System domain is always created under the owning organization s Private domain. The Default domain is created under the owning organization s Default or Private domain this is determined by a Private setting on the container. Product or a Library is set to private, their related Default domain is created under the owning organization s Organization s Private domain. Project or Program is set to private, their related Default domain is created under the owning organization s Organization s Private domain. For Projects and Programs, "Private" behavior comes from selecting "Members only in the Access group drop-down menu in the creation wizard. Large numbers of containers lead to very large numbers of domains. The figure 2 captures complexity behind domain implementation in the Windchill system. Figure 2. Only implement containers when really needed to minimize administration. Because of the container and domain model in Windchill, distributed and hierarchical administration is possible. This gives great flexibility but can lead to excessive complexity. In Windchill there is special tool to manage policy access called Policy Administrator.

5 K. Swirski, U. Zajkowska 157 The figure 3 present Windchill wizard. It can be used to viewed and updated domains. They can also be created, deleted, cut, and pasted, but in normal usage, this is not recommended. Policies can be implemented at any container level. TEWI administrator must ensure that only the appropriate participants have access to objects. Decisions about access rights are expressed as access control rules. Figure Access Controls Lists Access Controls Lists (ACLs) are the mechanism used to enforce access control. An ACL is generated for each object type, state, and domain. A given object is associated with the ACL whose domain, type, and state match that of the object, for example, all WTDocument objects of a given lifecycle state, within a given domain, are associated with the same ACL. An ACL for an object is obtained by combining all rules that apply to the object s type, state, and domain. To make this definition precise, it is necessary to describe how rules are combined, and when a rule applies to a type. A rule is applicable to a given type when the object type referred to in the access control rule is the type itself or one of its sub-types. For example, a rule that applies to the WTDocument type also applies to incident reports if IncidentReport is a soft type of WTDocument. Rules that apply to a type

6 158 Windchill Policy Administration within TEWI Administrative Domain are combined by merging rules that have the same sign (+ or ) and principal. The merge is performed by calculating the union of all permissions. There are two types of access control rules. Policy rules are set in domains for objects of a specific object type within a specific lifecycle state and grant, deny, or absolutely deny access control permissions to those objects. These rules determine the types of interactions participants can have with objects of the specified type and lifecycle state in the domain. Policy rules form an access control policy for the domain. Ad hoc rules are set on an object and grant access control permissions to the specific object. These rules determine the types of interactions participants can have with the object. Access control rules define who can access specific objects types, when they are accessed and what actions can be performed. Specify: Object Type, Lifecycle State, Principal, Permissions (Grant/Deny) Access Control Lists (ACLs) are generated from access control rules. There are two types of ACLs: policy: which apply to an object type ad hoc: which apply to a specific instance of an object type The ACL is the basic mechanism for enforcing access control decisions when a user attempts to interact with an object. ACLs are created upon demand and are cached to maximize system performance. Permission Represent right to perform an operation on an object Container Team Roles Second very important way to manage policy access is Container Team Roles and Policy Principals. Each role in a container team also has a related object: a pseudo group of the same name. If a custom role is added to the team, a pseudo group of the same name is created in the background. Pseudo groroups will show up in all caps in the access control Rule UI. Pseudo groups are not visible to nonadministrative users they are used primarily to simplify administration of team participation and access. Pseudo groups in TEWI projects are actually used as the policy principal. All users who join (access) a container will be added to this container s pseudo group called team members. The team members pseudo group can be used to define policies en masse for all users in the team. The specific role called guest role is intended to be used for infrequent contributors to a given container. It s common to use such role in TEWI for different projects where people from different Universities work together. For such specific user read access is

7 K. Swirski, U. Zajkowska 159 granted to business objects, but the user will not see the container in their Product/Library/Program/Project List pages. Domain-based access control policies can be applied at the folder level as well as the container level. Domains are assigning to folders during creation thereby granting accesses at the folder level. This capability is not enabled by default set Display Folder Domains preference. Windchill provides users and context managers more flexible control over access rights on business objects. The security management functionality provides a mechanism to view and manipulate access control permissions. Ad-hoc permissions work in concert with domain based access policies, but can only grant permissions, not deny Ad hoc permissions enable users, groups, or organizations to perform certain actions on objects. Provides single object, multi-object, and folder level access control This capability is a reworking of the ProjectLink Access Control action available in 8.0 and earlier Ad-hoc permissions are container specific policies are applied to (local) team roles and member principals only Want to drive toward policy-based access rather than ad-hoc access, for best Performance Profiles Different way to manage access is enable an administrator to control visibility to Windchill information and functions based on a user s ID or group membership. The goal is to provide users with just the information and capabilities they need and no more. The most typical motivation is to provide a focused set of information and actions to a supplier, partner, customer, or internal user. Such users may either be infrequent participants in a product or project, or do not understand certain actions or information. Profiles are not access-control mechanisms they are user interface mechanisms and control whether actions are displayed in the user interface they are very common in TEWI projects. The figure 4 present simply configuration of profiles in Windchill system. Profiles can be defined at Site and Organization contexts. Each user or group can be associated with one or more Profiles: Profiles rights are combined when a user is a member of more than one Profile. The least restrictive visibility rights are assumed:

8 160 Windchill Policy Administration within TEWI Administrative Domain Figure 4. If a user is associated with two Profiles where one hides an action, but the other enables visibility of that action, then the user will see the action. Profiles are inherited down the container hierarchy from Site to Organization to application context and are active in application containers: Inherited Profiles can be overridden by context managers using the Configure Actions for Roles function. Visibility to global attributes can be controlled using profiles. When a user is added to the system, the user will inherit the Profile that is associated with the Organization of which the user or group is a member. If the Organization to which the user is added is not associated with a profile, and the user is not associated with a Profile, then the user s visibility to actions and areas of the user interface will be determined by the default Profile system configuration. The user will not be associated with this default system Profile but the system will use this Profile for the user in the absence of any other Profile association. This system Profile may be modified by the site or system administrator to provide visibility to a minimal number of actions and information elements. TEWI user profile provides visibility to the Project, Product, Library, and Change Tabs but hides access to CAD data management functionality. Non-TEWI user provides visibility only to the Project Tab and hides global search, project search and home page search as well as all authoring functionality. Consumer Provides visibility to the Project, Product, Library, and Change tabs, but hides access

9 K. Swirski, U. Zajkowska 161 to all authoring functionality across libraries, products and project. CAD Author Provides visibility to the Project, Product, Library, and Change Tabs and CAD data management functionality. Procurement Provides visibility to the Project, Product, Library, Change, and Supplier Tabs but hides access to CAD data management functionality. Customer Provides visibility to only the Folders subtab of a Project, hiding forums, routings, and search functions as well as CAD data management. TEWI provides visibility to only the Project tab, and only the Folders, Team, and Discussions subtabs. Project Provides visibility to the Project tab and hides the Product, Library, Change, and Program Tabs as well as CAD data management functionality. PDM Provides visibility to Product, Change, and Library tabs and hides visibility to Project and Program tabs as well as CAD data management functionality. Profiles are defined and managed from the Site and Organization contexts. Profiles that are created in an Organization context are peers to the profiles created in the Site context, unless they are given identical names that is, the system will merge the settings from all Profiles that are associated with a user, regardless of whether they are defined at the Site or the Organization contexts in order to determine what will be visible to the user. For example, the TEWI user is associated with a Profile that is defined in the Site context and this profile does not enable visibility to the actions that would enable that user to create Folders in any application context. The Project Manager of that project can override the Site-defined Profile privileges and enable that specific user visibility to the action for creating folders by configuring the role for the team in which the user is a member. From the Team page, application context managers can override the visibility defined in site and organization profiles using the Configure Actions for Roles function. Context managers, Organization, and Site administrators can select the actions that members in a specific role are able to see using the Configure actions for roles function. This capability is similar to Profiles, in that it restricts visibility to action. Use the following steps to manage the visibility of actions for members in a specific set of roles. For example, to modify a TEWI team, you must be able to view the Team page. Therefore, it s not recommend to hide the View Team Page action for those roles where the Modify Team action is visible. If In TEWI project the roles are selected to be configured, rather than configuring all roles, the Team Members column is always shown. This column represents the settings for the Team Members group and the settings saved for this group are used for any roles that you add in the future. For those roles that have not been specifically configured, Windchill uses a default configuration for each role.

10 162 Windchill Policy Administration within TEWI Administrative Domain 2.4. Summary In most of the cases an access control rule for the domain applies to an object type. An ad hoc applies to a specific instance of that object type. This is the way how we give access to the specific document in TEWI projects. Ad-hoc ACLs can be specified within Lifecycle templates to grant permission to the lifecycle managed object or using Manage Security function. The ad hoc ACL, however, specifies only positive (+) permissions, it cannot be used to deny access to object. If the ad hoc ACL grants a permission that is denied in the policy ACL, the ad hoc rule supersedes the policy rule, and the access right is granted. It is possible to monitor any changes make to TEWI documents permission settings for the object as well as changes to the team members who have access to the object or be notified if the object has been shared. The Edit Access Control event keeps track of this information and can be used as part of a Subscription. Working with Windchill especially on TEWI projects it recommended to use some best practices for access control and container teams. Main rule is to keep access control rules to a minimum for ease of administration and maintenance. Use the team members pseudo group to grant permissions to all roles (except Guests). Pseudo groups for all added Roles are automatically added to team members pseudo group. Use Product Templates to set all access control rules where possible to ensure standardization of policies and simplify administration. Shared teams also provide complementary capabilities, with the added benefit that standard policies can be updated. Enable Guests to view container in List page. Following this rules make work easier not only for TEWi users but also for TEWI Administrators. Project donated by UE funds for science, years References [1] Praca Zespołowa, Studium wykonalności platformy TEWI, 2009, not published [2] Hong-Seok Park and Xuan-Phuong Dang, Structural optimization based on CAD integration and metamodeling techniques, Computer-Aided Design, Volume 42, Issue 10, Septemeber 2010, s [3] Martyn Day, Is PLM the New PDM?, CADDigest, 2004 [4] Group work, Windchill customizers guide, PTC 2009, not published

11 K. Swirski, U. Zajkowska 163 [5] Group work, Windchill business administration, PTC 20010, not published [6] Group work, Windchill business administration guide, PTC 2010, not published [7] Group work, Windchill system administration guide, PTC 2010, not published