security administration guide -...

Teamcenter 10.1

Security Administration Guide

Publication NumberPLM00101 I

Proprietary and restricted rights notice

This software and related documentation are proprietary to Siemens ProductLifecycle Management Software Inc.

© 2013 Siemens Product Lifecycle Management Software Inc. All Rights Reserved.

Siemens and the Siemens logo are registered trademarks of Siemens AG. Teamcenteris a trademark or registered trademark of Siemens Product Lifecycle ManagementSoftware Inc. or its subsidiaries in the United States and in other countries. Allother trademarks, registered trademarks, or service marks belong to their respectiveholders.

2 Security Administration Guide PLM00101 I

Contents

Proprietary and restricted rights notice . . . . . . . . . . . . . . . . . . . . . . . . . 2

Getting started with security administration . . . . . . . . . . . . . . . . . . . . . 1-1

About Teamcenter security administration . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Teamcenter security applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Understanding Teamcenter security administration . . . . . . . . . . . . . . . 2-1

What you need to know for Teamcenter security administration . . . . . . . . . . . 2-1Teamcenter object model hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1What is Authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Understanding Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3What is project-level security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16What is group-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16What is authorized data access? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16About effectivity and access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Multi-Site Collaboration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Controlling access to working data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

About controlling access to working data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1About configuring access to working data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Guidelines for applying the delete and change privileges . . . . . . . . . . . . . . . . 3-4Example of defining access controls on object class, type, and name . . . . . . . . . 3-4Controlling access to revision rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7Example of controlling access to effectivity . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Controlling access to in-process data . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

About controlling access to in-process data . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Workflow accessors and privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Workflow ACL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Parallel task and parallel process ACL conflict resolution . . . . . . . . . . . . . . . . 4-3Workflow access examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Controlling access to scheduling data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

About controlling access to scheduling data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Configuring security for remote export and remote checkout . . . . . . . . 6-1

About configuring security for remote export and remote checkout . . . . . . . . . 6-1

Configuring group-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

About configuring group-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

PLM00101 I Security Administration Guide 3

Contents

Example of configuring security to prevent suppliers from viewing internaldata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Example of configuring security for data owned by a supplier (external data) . . 7-3Example of configuring supplier security using hierarchical groups . . . . . . . . . 7-3Example of configuring security for special project data using hierarchical groups

(fully restrictive external group security) . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Configuring security for project and program data . . . . . . . . . . . . . . . . 8-1

About configuring security for project and program data . . . . . . . . . . . . . . . . 8-1What are projects and programs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1What are groups? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2Applying project and program security (Access Manager) rules . . . . . . . . . . . . 8-2Default security rules for project and programs administration . . . . . . . . . . . . 8-3Project-level security based on groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Granting user-based access to project data . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Granting role-based access to projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10Configuring security when a user is a privileged member of multiple projects . . 8-14Configuring security to protect competitive data when multiple suppliers are

members of a common project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16Implementation considerations for project-level security . . . . . . . . . . . . . . . . 8-17Program security examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17Implementation considerations for program-level security . . . . . . . . . . . . . . . 8-22

Configuring authorized data access (ADA) . . . . . . . . . . . . . . . . . . . . . . . 9-1

About configuring authorized data access (ADA) . . . . . . . . . . . . . . . . . . . . . . 9-1Configuring ADA for IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Configuring ADA for ITAR support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32

Controlling access to classification objects . . . . . . . . . . . . . . . . . . . . . 10-1

Controlling access to classification objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1Component display suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1Hierarchy component protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1ICO protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4Classification access privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4Applying access controls examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5

Controlling access based on compound property values . . . . . . . . . . . 11-1

About controlling access based on compound property values . . . . . . . . . . . . . 11-1Has Property condition example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Rule conditions, accessor types, and privileges . . . . . . . . . . . . . . . . . . . A-1

What are access rules composed of? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1Rule tree conditions by group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1Accessors by category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7Accessor precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9Access privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1

4 Security Administration Guide PLM00101 I

Chapter

1 Getting started with securityadministration

About Teamcenter security administration . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Teamcenter security applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

PLM00101 I Security Administration Guide

Chapter

1 Getting started with securityadministration

About Teamcenter security administrationSecurity administration is the process of establishing and maintaining control ofaccess to data in Teamcenter databases using access control lists (ACLs) and ruleconditions configured within the Access Manager rule tree. This guide describesbasic security administration concepts and tasks and it also provides examplesof different security implementations, such as project-level security, group-levelsecurity, and security for authorized data access.

This guide is intended for Teamcenter administrators who are responsible fordefining and implementing security controls, including but not limited to:

• Creating access rules and maintaining the rule tree.

• Creating access control lists (ACLs) corresponding to rules.

• Configuring project-level security to control access to data in specific projects.

• Configuring group security to control access for specific groups of users.

• Configuring authorized data access for International Traffic in Arms Regulations(ITAR) compliance and intellectual property (IP) protection.

It is assumed that the administrator is familiar with the Teamcenter data model,the organizational structure of the enterprise, and the business rules governingprocesses within the enterprise.

PrerequisitesYou must have administrative privileges to perform most security-related tasks. Inaddition, some tasks require you to have administrative privileges related to the typeof security being implemented. For example, you must have project administrator orproject team administrator privileges to perform project-related security tasks.

Teamcenter security applicationsThe following Teamcenter applications are used to implement security solutions:

• Access Manager

PLM00101 I Security Administration Guide 1-1

Chapter 1 Getting started with security administration

• Project

• Workflow Designer

Note If you have trouble accessing Teamcenter security applications, see yoursystem administrator; it may be a licensing issue.

1-2 Security Administration Guide PLM00101 I

Chapter

2 Understanding Teamcentersecurity administration

What you need to know for Teamcenter security administration . . . . . . . . . . . 2-1

Teamcenter object model hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

What is Authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Understanding Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3What is Authorization? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Rules-based protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Object-based protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Access control lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Access Manager rule tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5How rules work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

How rules are defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Rule syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Rule evaluation assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Evaluating the rule tree for the effective ACL . . . . . . . . . . . . . . . . . . 2-7Example rule tree evaluation by order of precedence . . . . . . . . . . . . . 2-8Example of compiling an effective ACL . . . . . . . . . . . . . . . . . . . . . . . 2-8Simple rule tree evaluation example . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Complex rule tree example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Good rule practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13Cautions for using rule trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

What is project-level security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

What is group-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

What is authorized data access? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

About effectivity and access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Multi-Site Collaboration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Remote checkout privilege access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18


Chapter

2 Understanding Teamcentersecurity administration

What you need to know for Teamcenter security administrationTeamcenter security administration requires an understanding of the object modelhierarchy, and the concepts of authentication and authorization. Authorizationis based on rules arranged hierarchically in the Access Manager rule tree and onobject-based protection that grants exceptions to the rules.

Teamcenter object model hierarchyThe following is a simplified illustration of the major concepts of the Teamcenterobject model hierarchy. It is important to understand the object model, as some ofthe security implementations described in this guide propagate information downthe hierarchy structure.


Chapter 2 Understanding Teamcenter security administration

Folder

Item

Form: Item Rev Master

Dataset: UG Master

BOMView Revision

Dataset: UG Part

Dataset: Direct Model Dataset

Dataset: Text

381-Pen Cap

381-Pen Cap/A

Item Revision

Engineering Change

Form: ECO Checklist

Item Master Relation

Specification Relation

Manufacturing Relation

BOMView Revision Relation

named references

cap_model.prt

cap_drawing.prt

cap_image.jt

Text describing the cap design

cap_spec.txt

Files

Metadata Physical DataDatabase

Volume

Product Structure Editor

Cost, material, ERP attributes

Note Master forms inherit their permissions from their parent item or itemrevision. You can use the TC_MASTERFORM_DELEGATE environmentvariable to change the default behavior. For more information, see thePreferences and Environment Variables Reference.

What is Authentication?Authentication refers to gaining access to a Teamcenter application or productsolution. Authentication to load applications, such as Structure Manager, in yourTeamcenter session is provided by the Siemens PLM Software Common LicensingServer daemon.

For more information, see the Installation on UNIX and Linux Servers Guide or theInstallation on Windows Servers Guide.

In addition to application authentication within Teamcenter, Security Servicesallows users to move from one Teamcenter product solution, such as TeamcenterEnterprise, to another solution, such as Teamcenter lifecycle visualization, withoutencountering multiple authentication challenges. Security Services includes thefollowing features:

• Single sign-on to Teamcenter products, for both the rich client and the thin client.

• Common authentication through LDAP v3-compliant directory servers, such asMicrosoft Active Directory and the Sun iPlanet Directory Server, which can becustomized to work with other authentication services.


Understanding Teamcenter security administration

• Interoperation with commercial single sign-on products.

• Lightweight directory access protocol (LDAP) referrals, which allow users to bedistributed across multiple LDAP servers.

Organizations (user bases) maintained on a corporate LDAP directory server canbe synchronized with Teamcenter using the ldapsync utility. The synchronizedorganization data is considered to be externally managed, and when maintainedusing the Teamcenter Organization application, is subject to restrictions that donot apply to internally managed organizations. For example, externally managedpasswords are never synchronized with Teamcenter and user status should not bemapped to an LDAP attribute. For more information, see the Organization Guide.

Security Services are installed and configured separately from Teamcenter 10.1.

Authentication can be implemented for performing Do tasks, Perform signoff tasks,Condition tasks, and Route tasks using the require-authentication handler.

Understanding Authorization

What is Authorization?Authorization refers to the implementation of rules that control access to specificdata stored in the Teamcenter database. Authorization to interact with data iscontrolled by a combination of global rules (rules-based protection) and object accesscontrol lists (ACLs) applied to specific objects that allow for exceptions to the globalrules (object-based protection).

Using rules and ACLs in combination with information about the user, such astheir group and project membership, nationality, and clearance level, enables you todesign and implement sophisticated security models to protect your data.

Rules-based protectionRules provide security for your Teamcenter data by:

• Controlling access to data on a global basis.

• Determining whether a user has permission to view or perform an action onan object.

• Filtering data according to the attributes of the data.

• Granting privileges to the data according to the users’ IDs and their sessioncontext (the group and role they used to log on).

Note Rules do not control the creation of objects. They only determine whatoperations can be performed on existing objects.

Rules are defined by a combination of:

• A condition.

• A value for the condition.



• An access control list (ACL) that grants privileges to accessors.

The condition and value identify the set of objects to which the rule applies; the ACLdefines the privileges granted to users (accessors).

User actions against objects cause the rule tree to be evaluated to dynamically buildan access control list for the object. The ACL controls permissions for the object anddetermines who (accessors) can do what (actions) to the object.

Object-based protection

Object-based protection uses access control lists (ACLs) to create exceptions torules-based protection on an object-by-object basis.

Object ACLs are most useful when you need to:

• Grant wider access to a specific object.

• Limit access to a specific object.

Teamcenter uses ACLs to determine access to an object. Users with properpermissions can override the ACL for an object to grant or deny permissions forcertain users but only when the rule tree allows.

For example, the rule tree does not allow object-based access rules to override therules-based protection when:

• An object has an assigned status.

• The object access rule is granted in a workflow.



Note ACLs do not control the creation of objects. They only determine whatoperations can be performed on existing objects.

• Each ACL contains a list of accessors and the privileges granted, denied,or not set for each accessor.

• Each individual pairing of an accessor with their privileges is considereda single access control entry (ACE).

Access control lists

Access control lists (ACLs) contain a list of accessors and the privileges granted,denied, or not set for each accessor. Accessors are collections of users who sharecertain common traits, such as membership in the group that owns the object ormembership in the project team. Just as rules have a precedence weighting in therule tree, accessor precedence weighting is considered when the ACL is evaluated.

Each pairing of an accessor with corresponding privileges in the list is referred to asan access control entry (ACE). An ACL can be comprised of one or many ACEs.

ACLs are associated with conditions in the rule tree as part of a rules-based securitymodel, and they can be used in more than one rule.

In addition, object ACLs grant exceptions to rules-based protection and are createdby users with change privileges.

Access control lists display the current protections for an object.

Note • If an ACL is modified by a user, other users who are logged on at thesame time are not affected by the updated ACL until they log off andlog on again.

• ACLs do not control the creation of objects. They only determine whatoperations can be performed on existing objects.

System Administrator

World

Access Manager rule tree

Rules are organized in the Access Manager rule tree and are evaluated based ontheir placement within the tree structure. The default rule tree included in yourTeamcenter installation assumes that users are granted privileges unless explicitlydenied.

The rule tree acts as a filter that an object passes through when a user attemptsto access the object. When conditions that apply to the selected object are met, theprivileges defined in the ACL are applied.

• The rules are evaluated from the top to the bottom of the tree.

• Rules at the top take precedence over rules at the bottom of the tree.



• Subbranches always take precedence over parent branches in the tree.

The rule tree appears to the left of the Access Manager window.

Has Class(POM_object)Has Bypass(true) –> BypassHas Class(POM_object) –> System ObjectsHas Class(WorkspaceObject)In Job(true)Has Status(TCM Released) –> TCM Released RuleHas Status( ) –> VaultHas Object ACL(true)Has Class(POM_application_object) –> Import/ExportIn Project( ) –> ProjectsOwning Group Has Security(Internal) –> Internal DataOwning Group Has Security(External) –> External DataHas Class(POM_application_object) –> Working

For a list of default rule conditions, see the Access Manager Guide.

How rules work

How rules are defined

Rules are defined by a combination of a condition, a value for that condition, and anaccess control list (ACL) that grants privileges to accessors.

• The condition and value identify the set of objects to which the rule applies.

• The ACL defines the privileges that are granted to users (accessors) specifiedin the ACL.

IF condition = value is TRUE, THEN apply ACL to object.

Example ACL

Accessor User Read Write Delete Change Promote Demote CopyWorld

Rule syntax

The following syntax applies to rules:

Condition {Value} –> ACL

The parts of the rule can be thought of as an IF clause and a THEN clause.

• The condition and value supply the IF part of the rule and examine the objectwith Boolean logic.



• The access control list (ACL) supplies the THEN part of the rule by describingthe access permission.

For example:

Has Type {UGMASTER} –> UG Model

In this example, Has Type is the condition, UGMASTER is the value, and UGModel is the name of the ACL.

Rule evaluation assumptions

When a user attempts to access data, the rule tree is evaluated to determinethe privileges to be granted or denied. The following assumptions apply to theevaluation:

• Rules higher in the rule tree are more global in nature and apply to all objecttypes.

• Lower-level rules refine access to more specific objects such as UGMASTERdatasets. For example:

Has Class(POM_app_object)

Has Class(Dataset)

Has Type(UGMASTER)

• Precedence determines the privileges granted. Rule precedence is from top tobottom in the tree, with the highest rule having greatest precedence and thelowest rule having least precedence.

For more information, see Evaluating the rule tree for the effective ACL.

• Accessor precedence in the ACL and rule precedence within the tree are bothconsidered when granting access privileges. Accessors have a predefinedprecedence in the system.

For more information, see Accessor precedence.

Note The way Access Manager evaluates Master forms does not follow thenormal rules. Master forms inherit access privileges from the parent itemor item revision, so if you change access privileges to an item or itemrevision, you affect the privileges on the Master form. You can use theTC_MASTERFORM_DELEGATE environment variable to change thedefault behavior.

For more information, see the Preferences and Environment VariablesReference.

Evaluating the rule tree for the effective ACL

The rule tree evaluation results in an effective ACL. The effective ACL representsthe cumulative compilation of all the named ACLs that apply to the object the useris trying to access.

The rule tree is evaluated as follows:



• Trim rules that do not apply to the object because their conditions are false.

Note The rules are not removed from the tree, but they are ignored duringevaluation.

• Evaluate rules in order of precedence, from top to bottom.

• Evaluate the subbranch of a rule before evaluating the parent rule.

• Evaluate subbranch rules in order of precedence, from top to bottom, in the eventthat there are multiple subbranch rules.

The effective ACL is determined by compiling the ACLs in the order that the treeis traversed.

Example rule tree evaluation by order of precedence

This example rule tree shows the order of precedence in the left column, assumingall conditions are met.

• The first two rows are the first two rules evaluated because they are highest inthe tree and have no subbranch.

• The third row only gets evaluated after all its subbranches are evaluated.

1 Condition {Value} –> Named ACL2 Condition {Value} –> Named ACL15 Condition {Value} –> Named ACL9 Condition {Value} –> Named ACL3 Condition {Value} –> Named ACL4 Condition {Value} –> Named ACL7 Condition {Value} –> Named ACL5 Condition {Value} –> Named ACL6 Condition {Value} –> Named ACL8 Condition {Value} –> Named ACL14 Condition {Value} –> Named ACL10 Condition {Value} –> Named ACL13 Condition {Value} –> Named ACL11 Condition {Value} –> Named ACL12 Condition {Value} –> Named ACL

Example of compiling an effective ACL

When the user attempts to access a UGMASTER dataset, the rule tree is trimmedto reflect only those rules that apply to the object.

Has Class(POM_object)

Has Class(POM_app_object) –> Working

Has Class(Dataset)

Has Type(UGMASTER) –> UGMASTER



Based on the trimmed rule tree, the effective ACL is compiled by evaluating the tree(from bottom to top) as follows:

1. Find the topmost leaf node in the tree, in this case, Has Type(UGMASTER) –>UGMASTER. Add the UGMASTER ACL to the effective ACL.

2. Find the next node, Has Class(Dataset). This node has no associated ACL, so itdoes not contribute to the effective ACL.

3. Find the next node, Has Class(POM_app_object) –> Working. Add theWorking ACL to the effective ACL.

4. Find the next node, Has Class(POM_object). This node has no associatedACL, so it does not contribute to the effective ACL.

The rule tree evaluation results in the following effective ACL.

Accessor

User Read Write Delete Change Promote Demote Copy ACL

Role in Owning Group Designer UGMASTER

World UGMASTER

Owning User Working

Group Administrator Working

Owning Group Working

System Administrator Working

World Working

The effective ACL is evaluated when a user attempts to access a UGMASTERdataset. The lines that do not apply to the user are ignored. For example, if you area designer in the owning group of the UGMASTER dataset, but you are not theowning user, system administrator, or group administrator, the following entries inthe ACL are applied when you try to access a UGMASTER dataset.

Accessor

User Read Write Delete Change Promote Demote CopyRole in Owning Group Designer

World

World

After the effective ACL is trimmed to include only the entries that apply to the userattempting to access the dataset, the privileges in the remaining ACL entries areevaluated. This is done by working down each privilege column until you encounter

a granted or denied symbol.



In this example, the privilege evaluation grants the accessor read, write, and copyprivileges and denies the accessor delete, change, promote, and demote privileges.

Simple rule tree evaluation example

This simplified view of the default rule tree is used in the following example:

Has Class(POM_object)Has Bypass(true) –> BypassHas Status( ) –> VaultHas Class(POM_application_object) –> Import/Export

A user, Jim Smith, attempts to open the MyDataset text dataset with releasedstatus. To perform this action, Jim Smith needs read privileges on the dataset.

The following ACLs are considered when the sample rule tree is evaluated:

1. The Has Bypass(true) –> Bypass rule is evaluated. This high-level rule grantssystem administration privileges to users.

Result: Jim does not have bypass set, nor is he a system administrator;therefore, this rule condition is false and the Bypass ACL is not applied. Theevaluation moves down the tree to the next branch.

2. The Has Status() –> Vault rule is evaluated. This rule evaluates whether theobject has an attached status type. If yes, the Vault ACL is applied.

Result: The MyDataset dataset is in released status; therefore, the rulecondition is true and the Vault ACL is applied.

Vault ACL

The Vault ACL grants all users read and copy privileges and denies all userswrite, delete, change, promote, and demote privileges. The World accessorrepresents all users.

Accessor

User Read Write Delete Change Promote Demote Copy CICOWorld

3. The Has Class(POM_application_object_) –> Import/Exportrule is evaluated. This rule evaluates whether the object is of thePOM_application_object class. If yes, the Import/Export ACL is appliedto the object.

Result: All workspace objects, including datasets, are subclasses of thePOM_application_object class; therefore, the rule condition is true and theImport/Export ACL is applied.

Import/Export ACL

The Import/Export ACL grants all users (world) export, import and transferin privileges and denies all users transfer out privileges. In addition, this ACLgrants remote site users import privileges and denies remote site users transferin privileges. The Import/Export ACL neither explicitly grants or denies readprivileges.



Accessor

User Read Export Import Transfer out Transfer inWorld

Remote Site

Complex rule tree example

This view of the default rule tree is used in the example that follows:


Has Bypass(true) –> Bypass

In Job(true)

Has Status( ) –> Vault

Has Object ACL(true)

Has Class(POM_application_object) –> Working

Has Class(Item) –> Items

Has Class(Item Revision) –> Item Revs

Has Class(Dataset)

Has Type(UGMASTER) –> UGMASTER

A user, Jim Smith (jsmith), a designer in the engineering group, attempts to modifythe MyPart UGMASTER dataset with working status. To perform this action, JimSmith needs write privileges on the dataset.

The following ACLs are considered when the sample rule tree is evaluated:

1. The Has Bypass(true) –> Bypass rule is evaluated. This high-level rule grantssystem administration privileges to users.

Result: Jim does not have bypass set, nor is he a system administrator,therefore, this rule condition is false and the Bypass ACL is not applied. Theevaluation moves down the tree to the next branch.

2. The In Job(true) rule is evaluated. This rule evaluates whether the objectis in a workflow.

Result: No ACL is defined, therefore, the condition being true has no effect. Theevaluation moves down the tree to the next branch.

3. The Has Status() –> Vault rule is evaluated. This rule evaluates whether theobject has an attached status type. If yes, the Vault ACL is applied.

Result: The MyPart dataset is in working status; therefore, the rule conditionis false and the Vault ACL is not applied.



4. The Has Object ACL(true) rule is evaluated. This rule evaluates whetheran ACL exists for the object.

Result: No object ACL is defined by a user; therefore, the condition is false andhas no effect. The evaluation moves down the tree to the next branch.

5. The Has Class(Item) –> Items rule is evaluated. This rule evaluates whetherthe object is of class item. If yes, the Items ACL is applied.

Result: The MyPart is of class dataset not item; therefore, the rule condition isfalse and the Items ACL is not applied.

6. The Has Class(Item Revision) –> Item Revs rule is evaluated. This ruleevaluates whether the object is of class item revision. If yes, the Items ACL isapplied.

Result: The MyPart dataset is of class dataset not item revision; therefore, therule condition is false and the Item Revs ACL is not applied.

7. The Has Type(UGMASTER) –> UGMASTER rule is evaluated. This ruleevaluates whether the object is of class UGMASTER. If yes, the Items ACL isapplied.

Result: The MyPart dataset is of class UGMASTER; therefore, the rulecondition is true and the UGMASTER ACL is applied.

UGMASTER ACL

The UGMASTER ACL explicitly grants write access to users who fill theDesigner role in the owning group and explicitly denies write access to all otherusers in the owning group.

Accessor

User Read Write Delete Change PromoteDemote CopyRole inOwning Group

Designer

Owning Group

8. The Has Class(Dataset) rule is evaluated. This rule evaluates whether theobject is of class dataset.

Result: The MyPart dataset is of class dataset; therefore, the rule condition istrue. No ACL is defined, therefore the condition being true has no effect.

9. The Has Class(POM_application_object) –> Working rule is evaluated. Thisrule evaluates whether the object is of the POM_application_object class. Ifyes, the Working ACL is applied to the object.

Result: All workspace objects, including datasets, are subclasses of thePOM_application_object class; therefore, the rule condition is true and theWorking ACL is applied.

Working ACL

The Working ACL explicitly grants write, delete, and change privileges toowning users and write privileges to the owning group. It also grants delete andchange privileges to the group administrator and the system administrator. All



other users are granted read and copy privileges and explicitly denied write,delete, change, promote, and demote privileges.

Accessor

User Read Write Delete Change Promote Demote CopyOwning User

Group Administrator

Owning Group


World

Result: After all the rules are evaluated, the following is the result. Note that theWorking ACL grants the owning group write permission, but the UGMASTERACL already removed that privilege. The figure also shows the applied named ACL.

Accessor

User Read Write Delete Change Promote Demote Copy Named ACLWorld Import

/ExportRemote Site Import/

ExportRole in OwningGroup

Designer UGMASTER

Owning Group UGMASTER

Owning User Working

User tsproxy(tsproxy)

Working

GroupAdministrator

Working

Owning Group Working

SystemAdministrator

Working

World Working

Good rule practices

• Understand your organization’s business rules.

A thorough understanding of your organization’s business rules enables you tomodel access rules that support your business processes and are transparent tousers. When modeled correctly, Access Manager rules grant users the privilegesrequired to perform the tasks associated with their jobs while denying themaccess to data that is released or out of the scope of their functional role.

• Document the business rules and the rule tree developed to meet them.



Every rule in the rule tree and the named ACLs associated with the rules areincluded for a purpose. For maintenance purposes, Siemens PLM Softwarestrongly recommends that you document the purpose of the rules, how they arepopulated, and why they have been populated. Future versions of Teamcenteradd new rules and accessors. Merging new rules and accessors is a manualprocess, which is simplified if you have thoroughly documented the AccessManager rule tree.

• Export the rule tree before and after making changes.

When new rules do not work as expected, you must be able to restore an earlier,working version of the rule tree. A backup copy is essential to restoring rulesback to their original state.

• Add new rules for working data in the Working data branch of the tree.

The proper location to add new rules for working data is under the Workingdata branch in the rule tree. This helps you customize your rule tree andidentify working data.


• Whenever possible, leave privileges unset.

Leaving privileges unset in ACLs allows rules to accomplish focused objectives,and it also allows objects and accessors to filter through rules that do not applyto them.

• Populate access control lists (ACLs) sparingly.

Explicitly grant privileges, and only deny privileges when you must block usersfrom access that would otherwise be implicitly granted.

• Use the Has Attribute condition to create custom rules based on anyattribute of an object of a given class.

For example:WorkspaceObject:object_name=*xPublicationRecord:security=suppliers

The class and attribute names are not case sensitive. The attribute type can bestring, double, integer, logical, or reference.

This rule supports custom attributes.

• Use the Has Property condition to create custom rules based on thevalue of compound properties.

For example:Item:my_custom_prop=my_custom_prop_value

In this example, Item is the type name and my_custom_prop is the compoundproperty.

For more information about using Has Property, see About controlling accessbased on compound property values.

For more information about creating compound properties, see the BusinessModeler IDE Guide.



• Set security precedence.

You can embed type-level security rules under project-level security rules to givethe type-level security rules higher precedence than the project-level securityrules. For example, the project administrator can add a subbranch under theHas Class (Form) rule entry to control access to certain form types that containsensitive data. The rule for the form type is written as follows:

Has Class(Form)Has Type(Finance) –> finance_acl

If your site requires that project-level security rules take precedence overtype-level security rules, you must embed project-level security rules under thetype-level security rules. However, Siemens PLM Software does not recommendthis practice.

• Define relevant ACL names.

ACL names are displayed in the rule tree and in dialog boxes throughoutthe Teamcenter interface. You can significantly enhance overall usability bydefining these names carefully. For example, when creating an ACL for workingdata, name it according to the data type (for example, item, item revision, orUGMASTER) rather than a role name or some other description.

Note ACLs can be referenced in more than one rule.

• Use discretion in applying the Bypass ACL.

The Bypass ACL grants all privileges to system administrators who haveselected the user Bypass setting. Use discretion in applying this ACL.

• Do not create GRM relations

Do not create Generic Relationship Management (GRM) relationships betweenTeamcenter business objects, such as BOM View, and Access Manager objects,such as AM Tree, Named ACL, and AM_ACE. Creating such relationships canresult in unpredictable behavior with Access Manager during run time.

Cautions for using rule trees• Do not modify access control lists (ACLs) referenced by rules on the

System Objects branch.

Adding new rules, deleting rules, or in any way modifying existing rules on theSystems Objects branch of the rule tree may result in unpredictable behavioror loss of data. Modifying the Systems Objects branch of the rule tree is notsupported unless specifically advised to do so by Siemens PLM Software.

• Do not modify the upper area of the rule tree.

Deleting or changing the order of the branches in this area of the rule tree mayresult in unpredictable behavior or loss of data.

• Do not use a text editor to modify rule tree files.

Rule tree files are simple ASCII files and conform to a particular format. Youcan read rule tree files using any text editor; however, modifying them with atext editor can easily corrupt the file.



• Do not use the infodba account to change object ACLs.

It is assumed that objects owned by infodba are seed parts or other special-caseobjects.

What is project-level security?Project-level security refers to a security scheme based on a combination of projectsand access rules in Teamcenter. Projects are entities that correlate groups of users,potentially at different physical sites, with the data associated with a given projector subset of a project.

In many industries, it is typical for a site to own a lead program in the productdevelopment environment. Other sites may share a project within the program oradd projects to the program. Users must have access privileges to the data thatthey own as well as to data assigned to the project that they work on that is ownedby other sites.

When suppliers are brought into the product development environment, the programowner, in addition to providing access to data owned by the supplier and dataassigned to the projects the supplier works on, must also control access to dataamong the suppliers. For example, Supplier A must not have access to data ownedby Supplier B, and conversely Supplier B must not have access to data owned bySupplier A.

For more information about implementing project-level security, see Aboutconfiguring security for project and program data.

What is group-level securityGroups represent collective bodies of users (group members) who share data. Groupmembers are assigned functional roles within a group. Users can be assignedmultiple roles within a group and they can also be members of multiple groups.Groups and roles within groups are often used as the basis for granting accessprivileges to data in Teamcenter.

Groups can be arranged in a hierarchy, which provides a powerful way of definingaccess rules for high-level groups that are implicitly inherited by lower-level groupsin the hierarchy. However, you can explicitly define access for a lower-level groupthat is subject to implicitly inherited access rules, and the explicitly defined accessrules override the inherited rules for that group.

Group-level security can also be combined with project-level security to control dataaccess privileges for internal users as well as for external users, such as suppliers.For more information, see About configuring group-level security.

What is authorized data access?Authorized data access (ADA) is a generic term that applies to the configurationof Teamcenter security for intellectual property (IP) data and for data that isdeemed military in nature and is, therefore, subject to International Traffic in ArmsRegulations (ITAR) policies.



ADA controls access to classified data using user clearance and authorizingdocuments (licenses) that grant limited-time access to specific users or groups ofusers. For more information about authorized data access, see About configuringADA for IP and About configuring ADA for ITAR support.

About effectivity and access controlAccess Manager allows you to control user access to create and edit effectivity.Effectivity is the point at which an object becomes effective or valid and can betracked by date or unit number. It is used in structure-based applications to indicateranges of dates or unit numbers for which the revision is effective.

You can specify a closed-ended or open-ended effectivity and make the effectivityspecific to an item.

Date effectivity allows you to specify a valid range of dates for a particular itemrevision. Unit effectivity allows you to specify a valid range of unit numbers for aparticular item revision. It is always specified in the context of an end item to whichthe units apply. You can specify a discrete, noncontinuous range, if appropriate. Toknow how you can use rules to determine who can create and edit effectivity, seeAccess to effectivity.

Multi-Site Collaboration considerationsMulti-Site Collaboration security mechanisms only apply Access Manager at thesite level. The remote site’s privileges are checked against the owning site’s AccessManager rule tree, but access to individual objects at the owning site are notvalidated against the individual remote user’s privileges. An individual remoteuser’s privileges are currently enforced by preferences set at the site protection level.This is an inadequate security mechanism.

Enhanced Multi-Site Collaboration security improves security of multi-siteoperations by allowing access to remote operations based on a user ID. Thisextends the current multi-site security mechanism, which applies AccessManager rules only at the site level. The administrator can set the preference,TC_check_remote_user_priv_from_sites, to turn on enhanced security for aremote user. This provides the ability to control the user’s privileges to performremote operations while maintaining site-level control.

This security mechanism is optional and is disabled by default. It can be enabledand configured using the preference TC_check_remote_user_priv_from_sites.The security checks are implemented in the IDSM server, allowing the enhancedsecurity feature to apply to client sites that do not implement the feature.

If enhanced security is turned on for a remote site, the following IDSM preferencesfor that remote site are ignored and the AM rule tree is used instead:

• IDSM_permitted_users_from_sites_site name

• IDSM_permitted_transfer_users_from_site_site name

• IDSM_permitted_checkout_users_from_site_site name



Remote checkout privilege access

The Remote Checkout privilege allows a user to check out objects that are notnormally modifiable, such as a released item revision. The intended purpose isto allow additional attachments or other incremental changes that do not requirewrite access to the object itself. If you import and check out an object that is notmodifiable, the local object permissions show that you have write access even thoughit is unmodifiable at the owning site. Any changes to the local object cause thecheckin to fail at the owning site.

The primary access check for a remote checkout operation is the Write privilege atthe owning site. The Remote Checkout privilege can be used to allow the remotecheckout of objects in which Write access is denied. Released objects are the mostcommon example where this is useful. Remote checkout is allowed if the Write orRemote Checkout privilege is granted at the owning site. A side effect of thisspecial behavior is remote checkout is permitted when the Remote Checkoutprivilege is denied if the Write privilege is granted.

An example usage scenario is you have released an item revision at the owning siteand you want to be able to run an analysis or tessellation on the replica side, attachthe output to the replica, and send the output back to the owning site. Becausereleased objects are write-protected, you cannot remote checkout the revision to dothis. The solution is to enable this operation by granting the Remote Checkoutprivilege to the revision at the owning site. Additionally, you need a way to get writeaccess to the replica revision at the replica site, such as by using the bypass rule.

For information about access rules, see What you need to know for Teamcentersecurity administration.


Chapter

3 Controlling access to workingdata

About controlling access to working data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

About configuring access to working data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Access to effectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Guidelines for applying the delete and change privileges . . . . . . . . . . . . . . . . 3-4

Example of defining access controls on object class, type, and name . . . . . . . . . 3-4

Controlling access to revision rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

Example of controlling access to effectivity . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8


Chapter

3 Controlling access to workingdata

About controlling access to working dataDetermining who should have privileges to access working data, and whichprivileges they should be granted, is an essential component of any Teamcentersecurity implementation. Privileges are assigned based on your company’s businesspractices and are commonly implemented by determining who has responsibility forthe data. For example, when determining who should have write access, you cangrant it to users in the following categories:

• Owning users

Granting write access to the owning user indicates that they are ultimatelyresponsible for the content and handling of the data.

• Owning groups

Granting write access to the owning group enables a teamwork approach tocreating and maintaining data. For more information and for examples ofgroup-level security implementation, see About configuring group-level security.

• Project members

Granting write access based on the projects to which data is assigned enables ateamwork approach to creating and maintaining data and allows the data to beeasily assigned to projects, upon which access is then defined. It also providesa mechanism to control access for suppliers. For more information and forexamples of project-level security implementation, see About configuring securityfor project and program data.

• Authorized users for classified data

Granting read access based on authorized data access concepts enables you toprotect intellectual property (IP) and data subject to International Traffic inArms Regulations (ITAR) policies using combinations of user authorization,object classification, and authorizing documents (IP and ITAR licenses). For moreinformation and examples of authorized data access (ADA) implementations, seeAbout configuring ADA for IP and About configuring ADA for ITAR support.

Note Although multiple users can be granted write privileges to data, the datacan only be modified by one user at any given time. This behavior is ensuredby implicit and explicit checkout.


Chapter 3 Controlling access to working data

About configuring access to working dataAccess to working data is configured by adding rules to the HasClass(POM_application_object) –> Working branch of the Access Manager ruletree. The Working ACL, which is delivered as part of your Teamcenter installation,configures access to working data of all object types, as shown in the following table.

Owning User

Owning Group


World

The Working ACL specifies the privileges for the following accessors:

• World

Grants all users (World) read and copy privileges to all data and denies write,delete, and other privileges to all other users. This is very important, because itprevents those privileges from being granted by rules elsewhere in the rule tree.

• Owning User

Grants write and delete privileges to all data that the user creates. In addition,the ACL grants change privilege, which allows the owning user to create objectACLs for data they own. This is a significant privilege and is often grantedonly to managers rather than to general users or groups of users. For moreinformation about using change privileges, see Guidelines for applying the deleteand change privileges.

• Owning Group

Grants write privileges to any user who is in the group that owns the data.

• System Administrator

Grants delete and change privileges to administrators.

Access to effectivity

You can use Access Manager to control who can create and edit effectivity by creatingthe rules shown.

The release status rule controls write access to the release status and who can attacheffectivity to it. This also determines who can initially create effectivity objects.Similarly, the effectivity rule controls who can edit an existing effectivity object.

Note You must ensure that the accessors who are granted write permissions in therelease status rule are also specified in the effectivity rule. If the accessorsare not specified in the effectivity rule, they cannot create effectivity objects.

For an example of controlling who can set effectivity, see Controlling access toeffectivity example.


Controlling access to working data


Has Class(ReleaseStatus) –> CreateEffectivityUsers

CreateEffectivityUsers ACL

World

Role Designer

Effectivity objects can be write-protected by selecting Apply Access Managereffectivity protection (Effectivity Protection) in the Create or Edit Effectivity dialogbox. If the flag is set to true, users cannot modify effectivity details. This behaviorcan be customized through the effectivity_protection attribute of the Effectivityclass.

For more information on editing revision effectivity data, see the Structure ManagerGuide.


Has Class(Effectivity) –> EditEffectivityUsers

Has Attribute (Effectivity:effectivity_protection=0) –>ModifyProtectedEffs

Has Attribute (Effectivity:effectivity_protection=1) –>RemoveProtection

ModifyProtectedEffs and RemoveProtection are the two ACLs that seteffectivity protection:

• ModifyProtectedEffs

List of accessor groups who are given write access to modify effectivity detailswhen the Effectivity Protection flag is set to false.

• RemoveProtection

List of accessors who are given write access to modify effectivity details whenthe Effectivity Protection flag is set to true.

EditEffectivityUsers ACL

Role Designer

Group ProjectAdministration

World



Guidelines for applying the delete and change privilegesThe following guidelines should be considered when applying the delete and changeprivileges:

• Delete

Delete privilege is generally limited to the owning user. However, you can alsogrant delete privileges to group administrators and system administrators forthe purpose of maintaining the database.

Tip You can establish a folder in which users can place data that they wantdeleted, and an administrator can be assigned responsibility for deletingthe data.

• Change

Caution must be used when granting change privileges. Change privilege allowsaccessors to define object ACLs that take precedence over rules in the AccessManager rule tree. Therefore, you can subvert the access rules by creating anobject ACL granting write privileges to the World accessor. For this reason, theHas Object ACL condition is placed lower in the rule tree than the In Joband Has Status conditions.

If change privileges are granted to the owning user, restrictions on changeprivileges can be applied for specific data types lower in the tree.

Example of defining access controls on object class, type, and nameYou can add rules to the Has Class(POM_application_object) –> Workingbranch to define access privileges at a more granular level, such as by object classand object type.

Rule tree configuration

The following rule tree configuration provides access controls based on object class,type, and name.

Has Class(Item) –> Items

Has Class(ItemRevision) –> Item Revisions

Has Class(Dataset)

Has Type(UGMASTER) –> UG Master

Has Type(UGPART) –> UG Non Master

Has Name(*dwg) –> UG Drawing

Has Name(*cam*) –> UG CAM

Has Class(PSBOMViewRevision)

Has View Type(Design) –> Design BOM



Has View Type(Manufacture) –> Manufacturing BOM

Has Class(Form)

Has Type(ItemRevisionMaster) –> Master Data

Has Type(MM Basic) –> MPR Data

Has Class(Folder)

Has Description(*Library*) –> Library Structure

Has Description(Library Node) –> Library Node

Roles used in working data rule tree exampleThe following roles are used in the working data rule tree example:

• Designer

Designers can edit UGMASTER and UGPART datasets and BOM viewrevisions of type design. They can also create new item revisions.

• Draftsmen

Draftsmen can only edit UGPART datasets which contain drawing files.

• Production Engineers

Production engineers can only edit UGPART datasets, which are CAM datawith the string cam in the dataset name. They can also edit BOM view revisionsof the view type Manufacture.

• Manager

Managers can create new item revisions, and they have change privileges toitem revisions.

• Librarian

Librarians can write to folders that have the name Library. All other users onlyhave write access to folders with the name Library Node.

Access control lists (ACLs)The ACLs used in the working data rule tree example control privileges to workingdata.

Items ACL

Role In Owning Group Manager

Role In Owning Group Designer

Role Marketing

World



Item Revisions ACL

Role In Owning Group Manager

World

UG Master ACL

Owning User

Role In Owning Group Designer

World

UG Non-Master ACL

Owning User

Role in Owning Group Designer

Role in Owning Group Draftsman

Role in Owning Group Production engineer

World

Design BOM ACL

Owning User


Role in Owning Group Configurator

World

Manufacturing BOM ACL

Owning User

Role in Owning Group Production Engineer

World

MRP Data ACL



Role in Owning Group Production Engineer

World

Master Data ACL

Owning User


Role in Owning Group Production engineer

World

Library Structure ACL

Role Librarian

World

Library Node ACL

Role Librarian

World

Controlling access to revision rulesUse Access Manager to control user access to revision rules. You can limit readaccess to control the users who can see and use a revision rule. You can use thistechnique to reduce the number of inapplicable revision rules that are presented toordinary users, or to restrict rules to certain groups of users. You can use writeaccess to control the users who can modify a revision rule.

You can apply an Access Manager rule globally to all rules using a class revision ruleor other attribute, (for example, OwningGroup) if you created the revision rulesappropriately. You can add object ACLs to specific revision rules for exception cases.A typical default Access Manager (AM) rule and rule tree ACL follow:

Access Manager rule:HasClass (RevisionRule) -> Private Rev Rule ACLOwningGroup (dba) -> Public Rev Rule

Private revision rule ACL:



This ACL prevents Teamcenter displaying privately created revision rules toall users. Only the owning user and system administrator have access to theprivate rule. You can define an entry for owning user that gives access to allusers in the owning group. Alternatively, you could add it as an object ACL tothe specific rule.

Owning User: Read, Write, Delete, Copy, ChangeSystem Administrator: Read, Write, Delete, ChangeWorld: No Read, No Write, No Delete, No Copy, No Change

Public revision rule ACL:

This ACL ensures that public revision rules are visible to all users. It also onlyallows users with a configuration role or members of a system administrationgroup to modify public rules. You should control these permissions carefully, asunintended modification of revision rules can have significant consequences.

Role = Configurator: WriteSystem Administrator: Write, Delete, ChangeWorld: Read, No Write, No Delete, No Copy, No Change

Example of controlling access to effectivityThis example shows how to configure the Access Manager rule tree to control whocan create, modify, or delete effectivity on a release status object. It also explainshow the Access Manager effectivity protection is configured and used. Effectivityprotection provides a method of preventing modifications to an existing effectivity.

In the example, Company X would like to allow people in the role of engineeringplanner or supervisor/charge person to be able to create, modify, or delete theeffectivity of in-work and pending release status objects. If the release status objectis anything other than in-work or pending, no effectivity can be created against thatobject. Once the effectivity is created, Company X would like to lock it so it cannot bechanged, or it can only be changed by a select group of users.

Add the following rules (those in bold) at the bottom of the rule tree:

Has Class(POM_object).........

Has Class (ReleaseStatus) –> WorldNoWriteHas Attribute (ReleaseStatus:name=In-Work) –>CreateEffectivityUsers

Has Attribute (ReleaseStatus:name=Pending) –>CreateEffectivityUsers

Has Class (Effectivity) –> WorldNoWriteHas Attribute (Effectivity:effectivity_protection=1) –>RemoveEffProtect



Has Attribute (Effectivity:effectivity_protection=0) –> ModifyEffectivity Users

The ACLs used in the controlling effectivity example control who can set effectivity.

WorldNoWrite ACLDenies write privilege to the world. It is applied to the Has Class (ReleaseStatus)and Has Class (Effectivity) branches to prevent anyone from writing to releasestatus or effectivity objects.

World

CreateEffectivityUsers ACLGrants write privilege to the roles of engineering planner and supervisor/chargeperson. The ACL allows users with any of these roles to create new effectivities.

Role EngineeringPlanner

Role Supervisor/ ChargePerson

AddEffectivityProtection ACLGrants write privilege to the roles of DBA, engineering planner, andsupervisor/charge person.

The ACL allows users with any of these roles to modify any existing effectivity, aslong as that effectivity does not have effectivity protection set. It also allows them toset effectivity protection.

Role DBA

Role Engineering Planner

Group Supervisor/ ChargePerson

RemoveEffProtect ACLGrants write privilege to the roles of DBA and EffectivityProtectionRemover.

The ACL allows users with any of these roles to remove effectivity protection so theeffectivity can be edited.

Role DBA



Role EffectivityProtectionRemover

Note • Any accessor in the CreateEffectivityUsers ACL that needs to createeffectivities must also be in the AddEffectivityProtection ACL. This isbecause to create effectivity you must have write privilege to the releasestatus and effectivity object.

• The Access Manager’s role in the Owning Group accessor does not applyto nonworkspace objects, so you must use the role accessor. This meansany engineering planner or supervisor/charge person can create and editeffectivity on any pending or in-work release status object.


Chapter

4 Controlling access to in-processdata

About controlling access to in-process data . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Workflow accessors and privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Workflow ACL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Parallel task and parallel process ACL conflict resolution . . . . . . . . . . . . . . . . 4-3

Workflow access examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3


Chapter

4 Controlling access to in-processdata

About controlling access to in-process dataAccess privileges to data that is in process (data that is the target in a workflowprocess) are controlled using the In Job rule condition. Unlike other ruleconditions, you do not associate an access control list (ACL) directly with the InJob condition. If the condition is evaluated as being true, the system applies theACL associated with the current task in the workflow process. The system usesthe EPM-set-rule-based-protection handler to determine the appropriate ACLto be applied.

Note If you associate ACLs directly with the In Job condition, they are ignoredwhen the rule tree is evaluated. Only ACLs associated with the workflowprocess are used to grant access.

The EPM-set-rule-based-protection handler passes information to AccessManager to determine which named ACL to use while the associated task handleris current or started. For example, if this handler is placed on the Start action ofa Review task, when the task starts, the named ACL specified in the handler’sargument is the ACL used by Access Manager to determine access rights for thetarget objects of the workflow process. The ACL is applied to the task and allsubsequent tasks in the workflow process unless it is changed by another instance ofthe EPM-set-rule-based-protection handler or the process completes.

If the EPM-set-rule-based-protection handler is not defined, the system uses theworkflow ACL. The current workflow ACL stays in effect until the same workflowsets another ACL later in the process or the process completes.

Workflow ACLs are created in the Workflow Designer application within the contextof a specific task and are considered an attribute of the task. For more informationabout editing task attributes, see the Workflow Designer Guide.

Workflow accessors and privilegesIn addition to the In Job rule condition, the following accessors and privileges areused to control access to in-process data:

Workflow accessors

• Approver (RIG)


Chapter 4 Controlling access to in-process data

Users who are members of a sign-off team in a workflow process with a specificrole in a specific group (RIG).

Note This accessor is used only in workflow ACLs and must match the signoffrole-in-group requirements for the release level associated with theworkflow ACL.

• Approver (Role)

Users in a specific role who are members of a sign-off team in a workflow process.

Note This accessor is used only in a workflow ACL.

• Approver (Group)

Users in a specific group who are members of a sign-off team in a workflowprocess.


• Approver

Users who are members of a sign-off team in a workflow process regardless oftheir role and group.


• Task Owner

User who is granted privileges for the task’s target data.

• Task Owning Group

Group that is granted privileges for the task’s target data.

• Responsible Party

Users responsible for performing a particular task. This ensures that only theuser assigned as the responsible party is given privileges to the task’s target data.

Workflow privileges

• Promote

Specifies whether the accessor is authorized to move a task forward in aworkflow process.

• Demote

Specifies whether the accessor is authorized to move a task backward in aworkflow process.

Workflow ACL exampleThe ApprovalACL ACL grants privileges to sign-off team members using theWorld accessor (all users) and the Approver(RIG) accessor.


Controlling access to in-process data

Approver(RIG) Engineering Manager inhigh_performance

World

The World accessor is explicitly granted read and copy privileges and is explicitlydenied write, delete, change, promote, demote, and change ownership privileges.

The Approver(RIG) (Engineering Manager in the high_performance group) isexplicitly granted promote privileges.

In addition, the privileges set for the World accessor (with the exception of thepromote privilege) are implicitly inherited by the Approver(RIG) accessor.

Parallel task and parallel process ACL conflict resolutionWhen multiple workflows set named ACLs concurrently, the logical OR applies tothe competing workflow ACLs. To determine privileges allowed to a user of an objectin process, the system uses a simplified processing scheme.

All ACLs associated with the object in the workflow process are taken into account.

• When one ACL grants a privilege, access is granted.

• When no ACL grants a privilege, but one or more ACLs denies it, access is denied.

• When no ACL grants or denies the privilege, access is neither granted nor denied.

Workflow access examplesThe following examples illustrate possible scenarios in which two tasks compete toapply privileges to the same target object.

Scenario 1

The user is a member of Group B.

The Task 1 named ACLgrants read privileges toGroup A.

The Task 2named ACLgrants read andwrite privileges toGroup B.

Result: The user is granted readand write privileges.

Scenario 2

The user is a member of Group B.

The Task 1 named ACLgrants read privileges toGroup B.

The Task 2named ACLgrants read andwrite privileges toGroup B.



Chapter 4 Controlling access to in-process data

Scenario 3

The user is an approver on Task 2.

The Task 1 named ACLgrants read privileges tothe Approver accessor.

The Task 2named ACL grantsread and writeprivileges tothe Approveraccessor.


Scenario 4

The user is an approver on Task 1 and Task 2.




Scenario 5

The user is the responsible party on Task 2.


The Task 2named ACL grantsread and writeprivileges to theResponsibleParty accessor.


Scenario 6

The user is the responsible party on Task 1 and an approver on Task 2.

The Task 1 named ACLgrants read privileges tothe Responsible Partyaccessor.



Scenario 7

The user is the responsible party on both tasks.

The Task 1 named ACLgrants read privileges tothe Responsible Partyaccessor.

The Task 2named ACL grantsread and writeprivileges to theResponsibleParty accessor.


Scenario 8

The user is a member of the task_owner_group group on Task 1 and is a memberof the approver_group group on Task 2.


Controlling access to in-process data

The Task 1 named ACLgrants read privileges tothe task_owner_groupgroup.

The Task 2named ACL grantsread and writeprivileges to theapprover_groupgroup.



Chapter

5 Controlling access to schedulingdata

About controlling access to scheduling data . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1


Chapter

5 Controlling access to schedulingdata

About controlling access to scheduling dataSchedule Manager enables you to plan and track activities in Teamcenter. You canconfigure Access Manager rules to control which users have the privileges requiredto access scheduling objects in the database. For more information about ScheduleManager concepts, see the Schedule Manager Guide.

The Access Manager rule tree provides default rules for scheduling objects.


Has Bypass(true) –> Bypass

Has Class(POM_object) –> System Objects

Has Class(WorkspaceObject)

In Job(true)

Has Status(TCM Released) –> TCM Released Rule

Has Status() –> Vault

Has Object ACL(true)

Has Class(POM_application_object) –> Import/Export

In Project() –> Projects

Owning Group Has Security(Internal) –> Internal Data

Owning Group Has Security(External) –> External Data


Has Type(NXDerived) –> NXDerived Access

Is GA(true) –> GA Working

Has Class(Item)

Has Type(Schedule) –> Scheduling Objects

Has Class(ItemRevision)


Chapter 5 Controlling access to scheduling data

Has Class(Dataset)

Has Class(PSBOMViewRevision)

Has Class(Form)

Has Type(ScheduleTaskRevisionExecution) –> Scheduling ExecutionObjects

Has Type(ScheduleTaskRevisionFixedCost) –> Scheduling Cost Objects

Has Type(ScheduleRevisionFixedCost) –> Scheduling Cost Objects

The following access control lists (ACLs) are used in the default rules to controlaccess to scheduling objects: Scheduling Objects ACL, Scheduling Cost ObjectsACL, and Scheduling Execution Objects ACL.

The Scheduling Objects ACL controls access to most scheduling objects andis configured as follows.

Owning User

Role Resource Graph Viewers

RoleInSchedule Coordinator

RoleInSchedule Observer

RoleInSchedule Participant

Public Schedule

World

The Scheduling Cost Objects ACL controls access to costing forms in a scheduleand is configured as follows.

Owning User


World

The Scheduling Execution Objects ACL controls access to execution objects.Execution objects contain data associated with tasks, such as the actual start date,actual end date, work complete, and percent complete.

Owning User

Role Resource Graph Viewers


Controlling access to scheduling data


RoleInSchedule Observer

RoleInSchedule Participant

Public Schedule

World


Chapter

6 Configuring security for remoteexport and remote checkout

About configuring security for remote export and remote checkout . . . . . . . . . 6-1


Chapter

6 Configuring security for remoteexport and remote checkout

About configuring security for remote export and remote checkoutYou can gain access to the target data of tasks in your remote inboxes by using theRemote Checkout option or by using the Remote Export option.

The Remote Checkout option provides access to modifiable replicas of the targetdata associated with the tasks assigned to you. It gives you write access to thereplica object and also prevents other users at other sites from modifying the objectbefore you can complete your changes. A reservation is created on the master copyat the owning site. This reservation not only prevents other users from checkingout the master copy but also prevents them from transferring site ownership byeffectively placing a lock on the master copy.

The Remote Export option allows you to read-only replicas of data or to transfer siteownership of the data required to perform your tasks.

The Remote Checkout and Remote Export options require that certain AccessManager (AM) rules be configured for both the user performing the operation and forthe target remote sites.

AM rules related to Multi-Site Collaboration activities are specified in theImport/Export ACL, which is configured as follows.

World

Remote Site

The export and transfer out privileges apply to local users at a local site using theRemote Checkout and Remote Export options. The import and transfer inprivileges apply to the remote site that is the target of the operation.

For remote workflow operations, you can create AM rules using the In Job conditionand the Import/Export ACL.

The Import/Export ACL grants the following privileges:

• All users have export privileges, which means that anyone can export an objectwithout transferring ownership.

• All remote sites can receive the objects being sent by the operation (importprivilege).


Chapter 6 Configuring security for remote export and remote checkout

• Transfer of ownership is not allowed to any remote site. The transfer in privilegeis denied.


Chapter

7 Configuring group-level security

About configuring group-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Example of configuring security to prevent suppliers from viewing internaldata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Example of configuring security for data owned by a supplier (external data) . . 7-3

Example of configuring supplier security using hierarchical groups . . . . . . . . . 7-3

Example of configuring security for special project data using hierarchical groups(fully restrictive external group security) . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4


Chapter

7 Configuring group-level security

About configuring group-level securityGroups represent collective bodies of users (group members) who share data. Groupmembers are assigned functional roles within a group. Users can be assignedmultiple roles within a group and they can also be members of multiple groups.Groups and users roles within groups can be used as the basis for granting accessto data in Teamcenter.

Groups can be arranged in a hierarchy, which provides a powerful way of definingaccess rules for high-level groups that are then implicitly inherited by groups thatare lower in the hierarchy. However, if access is explicitly defined for a lower levelgroup that is also subject to implicitly inherited access rules, the explicitly definedaccess rules override the implicitly inherited rules for that group.

Note Group inheritance does not apply to the Owning Group accessor type.

To better understand the examples, you should first understand the rule conditions,access control lists (ACLs), and accessors that comprise the Access Manager rules, aswell as the groups and their specified security levels that are used in the examples.

Rule condition Description

Owning Group Has Security Evaluates whether the owning group of theobject has a security string. This condition istrue only if the security value of the owninggroup is equal to the value of this condition.

Owning Group Evaluates whether the object is owned by thegroup specified in the group-name argument ofthe condition.

Wildcard characters can be used with theOwning Group condition to allow you to definerules applying to a group and all its subgroups.For example, assume that the Design grouphas two subgroups: Analysis.Design andDevelopment.Design. By defining a value forthe Owning Group condition using a wildcard,you can define a general rule to control privilegesto all data owned by the Design group and itssubgroups.

Note Subgroup names, when displayed outof the context of the tree structure,are formatted with the lowest group


Chapter 7 Configuring group-level security

Rule condition Descriptionin the hierarchy listed first and thehighest group listed last. For example,the subgroup name Analysis.Designindicates that the Design group is aparent of the Analysis subgroup.

For example:

Owning Group(“*Design) –> design_group_acl

ACL Description

internal_group_acl Grants read and modify privileges to the groupthat owns the data, grants read privileges toother internal groups, and denies privileges toexternal groups.

Accessor Description

Owning Group Group that owns the object. Usually, it is thegroup of the user creating the object. Additionalprivileges (for example, write) may be granted tothe owning group, because it is common for usersto share data with other members of their group.

Groups with Security Users who have the given security value,either Internal or External. This value is usedto distinguish between groups in the parentcompany (internal) and suppliers (external).

Groups Security level

Design Internal

Development Internal

Manufacturing Internal

Supplier 1 External

Supplier 2 External

Example of configuring security to prevent suppliers from viewinginternal data

In this example, access to data owned by internal groups is granted to users ininternal groups, but access is denied to external suppliers.

Use the following rule that specifies privileges for all data owned by users whoare members of internal groups:

Owning Group Has Security(Internal) –> internal_group_acl


Configuring group-level security

The internal_group_acl ACL controls read access and also allows the owninguser to modify access privileges (define object ACLs for exceptions to the rule-basedsecurity).

Owning Group

Groups with Security Internal

Groups with Security External

Example of configuring security for data owned by a supplier (externaldata)

In this example, read access to data owned by a specific external supplier is grantedto users in internal groups, and access is denied to external groups other than theowning group. The external owning group, supplier, has read and write access totheir data.

Use the following rule that defines privileges for all data owned by users who aremembers of external groups:

Owning Group Has Security(“External”) –> external_group_acl

The external_group_acl ACL controls read and write privileges for the owninggroup and grants read privileges to internal groups. External groups are deniedread privileges.

Owning Group



Example of configuring supplier security using hierarchical groupsThe security implemented in Example of configuring security to prevent suppliersfrom viewing internal data and Example of configuring security for data owned bya supplier (external data) can also be implemented by using the Owning Groupcondition to define a security rule granting all internal users read privileges to dataowned by internal groups. To do this, you must first create a hierarchical groupstructure (using the Organization application) with one root group containing allinternal groups and another root group containing all external groups.


Chapter 7 Configuring group-level security

Based on this hierarchical group structure, you can grant all internal groups readprivileges to company-owned data and deny supplier groups read privileges tocompany-owned data by writing the following rule:

Owning Group(“*InternalGroups”) –> group_read_acl

Owning Group

Group InternalGroups

Group ExternalGroups

You can set the Owning Group condition to define a security rule that grants allexternal users read privileges to data owned by external groups. Again, this methodrequires the appropriate hierarchical group structure.

Owning Group(“*ExternalGroups”) –> suppliers_acl

Owning Group



Example of configuring security for special project data usinghierarchical groups (fully restrictive external group security)

In this example, ABC Part Company wants to implement a strict security rule toprotect some of the data owned by one of their suppliers. To do this, they extendedthe hierarchical group structure.


Configuring group-level security

Note Subgroup names, when displayed out of the context of the tree structure,are formatted with the lowest group in the hierarchy listed first and thehighest group listed last. For example, the subgroup name Analysis.Designindicates that the Design group is a parent of the Analysis subgroup.

Based on this hierarchical group structure, the following rule can be defined toprevent access to supplier data by users who do not belong to the specific suppliergroup:

Owning Group(“*.SuppliersExclusive.*”) –> suppliers_exclusive_acl

Note To make the restricted security of this rule work effectively, the suppliergroup must only transfer existing data and create new data when they arelogged on as a member of one of the subgroups of the SuppliersExclusivegroup.

The suppliers_exclusive_acl ACL has the following definition.

Owning Group



Tip The security implemented in this example can also be achieved by usingthe In Project condition and adding the data to be protected to a specialproject. For more information, see About configuring security for projectand program data.


Chapter

8 Configuring security for projectand program data

About configuring security for project and program data . . . . . . . . . . . . . . . . 8-1

What are projects and programs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

What are groups? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Applying project and program security (Access Manager) rules . . . . . . . . . . . . 8-2Preferences related to project and program security . . . . . . . . . . . . . . . . . 8-3

Default security rules for project and programs administration . . . . . . . . . . . . 8-3Access rules for projects and programs . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3In Current Program rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4In Inactive Program rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4Is Program Member rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4In Invisible Program rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5In Project rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5Is Project Member rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6Is Owned by Program rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

Project-level security based on groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

Granting user-based access to project data . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Configuring user-based access to project data . . . . . . . . . . . . . . . . . . . . . 8-8

Granting role-based access to projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10Configuring role-based access to project data . . . . . . . . . . . . . . . . . . . . . . 8-11

Configuring security when a user is a privileged member of multiple projects . . 8-14

Configuring security to protect competitive data when multiple suppliers aremembers of a common project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16

Implementation considerations for project-level security . . . . . . . . . . . . . . . . 8-17Placement of rules in the Access Manager rule tree . . . . . . . . . . . . . . . . . 8-17Set security precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

Program security examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17About the program-level security examples . . . . . . . . . . . . . . . . . . . . . . . 8-17Example 1 — Grant read access to only team members of object’s assigned

projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18


Example 2 — Grant read access to all team members . . . . . . . . . . . . . . . . 8-18Example 3 — Grant read access to item to all team members to all data in

project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19Example 4 — Grant access to single item . . . . . . . . . . . . . . . . . . . . . . . . 8-20Example 5 – Deny read access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21

Implementation considerations for program-level security . . . . . . . . . . . . . . . 8-22

Security Administration Guide PLM00101 I

Chapter

8 Configuring security for projectand program data

About configuring security for project and program dataProject-level security refers to a security scheme based on a combination of projectsand access rules in Teamcenter. Projects are entities that correlate groups of users,potentially at different physical sites, with the data associated with a given projector subset of a project.

Program-level security refers to a security scheme based on a combination of projectsthat are configured to use program security and the corresponding program accessrules in Teamcenter.

What are projects and programs?Projects and programs organize data and are the basis for granting data access toproject and program team members. The following concepts apply to projects andprograms:

• Only privileged team members or regular team members who are explicitlygranted ASSIGN_TO_PROJECT or REMOVE_FROM_PROJECT privilegescan assign data to and remove data from projects and programs.

The TC_project_validate_conditions preference controls which team rolesand access privileges are required to add and delete projects.

• Project and program names must be unique within your site. Projects andprograms cannot have the same name as any group at the site.

• Data can be assigned to or removed from projects and programs manually orautomatically when the data item is created, and items can be assigned to morethan one project or program.

• Propagation rules define the associated data that is implicitly assigned to aproject or program when a primary item is assigned to the project or program.

• All items in a complete product structure can be assigned to a project or programusing the update_project_bom utility.

• Ownership of data can be assigned to a project or program by configuring theautoAssignToProject extension in the Business Modeler IDE.

For more information, see the Project and Program Guide.


Chapter 8 Configuring security for project and program data

• Creation and maintenance of data can be restricted to within the context of aprogram.

Note When the program security attribute on a project is set to true, the projectis considered to be a program and is subject to program-level access rules.

Programs offer all the basic features of projects, but in addition you can:

• Control access to program data at a higher level than typically appliedto project data.

• Share data between programs by assigning the data to multipleprograms.

For more information, see About configuring security for project and programdata.

What are groups?Groups organize users and play an important role in access control for projects andprograms. The following concepts apply to groups:

• Access to data is generally determined based on the owning group.

• Groups can be categorized as being Internal or External. This allows you todifferentiate between internal users and suppliers when granting data access.It also allows you to protect supplier data from being accessed by unauthorizedinternal users or by other suppliers.

• Groups can be structured in a hierarchy that allows access controls to beinherited by subgroups, because members of subgroups are implicitly membersof the parent group on which the access controls are implemented.

Note Groups are defined and maintained using the Organization application.

Applying project and program security (Access Manager) rulesProject administrators can extend the default security rules, which grant readaccess to project or program data to members of the project or program team, on aproject-by-project or program-by-program basis.

Note Project administrators only have access to the In Project() –> Projectsbranch of the rule tree.

Using the Project branch in the rule tree, you can:

• Grant or deny access to a particular group of users by applying the OwningGroup condition.

• Grant or deny access to groups of users based on the group’s categorization asinternal (OEM) or external (supplier) by applying the Owning Group HasSecurity condition.


Configuring security for project and program data

• Grant access to data assigned to projects by applying the In Project condition.

Note This rule is applied by default to any object assigned to an active project.

• Grant or deny access to users based on their membership in a project by applyingthe Is Project Member condition.

• Grant or deny access to users based on their membership in a program byapplying the Is Program Member condition.

• Deny users access to data if the owning program is not the active program in theuser’s session by applying the In Current Program condition.

• Deny users access to data if the owning program is inactive by applying the InInactive Program condition.

• Deny users access to data if the owning program is invisible by applying the InInvisible Program condition.

• Grant or deny access to program data by applying the Is Owned By Programcondition.

For more information about configuring project-level security rules, see Aboutconfiguring security for project and program data.

Preferences related to project and program securityThe preferences in the following table affect the way that security rules areevaluated for data in projects and programs.

Preference Description

AM_PROJECT_MODE Determines whether the system evaluates rolesin all active projects or whether only the role inthe user’s current project is evaluated.

TC_project_validate_conditions

Determines how the Assign to project andRemove from project access privilegesare validated in conjunction with privilegedmembership validation.

Default security rules for project and programs administration

Access rules for projects and programsThe Access Manager rule tree delivered as part of the standard Teamcenterinstallation includes the following rules related to programs and projects:

• In Current Program(false) –> Not Current Program

• In Inactive Program(true) –> Inactive Program

• Is Program Member(true) –> Not Program Member



• In Invisible Program(true) –> Invisible Program

• In Project() –> Projects

• Is Project Member(true) –> Project Objects

• Is Owned By Program() –> Projects

For more information about applying program-level and project-level security rules,see About configuring security for project and program data.

In Current Program rule

The In Current Program(false) –> Not Current Program rule denies write,delete, change, and export privileges to users if the owning program of the data isnot the active program for the user’s session.

The Not Current Program ACL denies the privileges to the data in a program,as follows.

ReadWorld

The World accessor denies write, delete, change and export privileges to users if theowning program of the data is not the active program for the user’s session.

In Inactive Program rule

The In Inactive Program (true) –> Inactive Program rule denies write,delete, change and export privileges to users if the owning program of the datais in the inactive state.

The Inactive Program ACL denies write, delete, change and export privilegesto the data in the program, as follows.

ReadWorld

The World accessor denies write, delete, change and export privileges to users ifthe owning program of the data is in the inactive state.

Is Program Member rule

The Is Program Member(false) –> Not Program Member rule denies readaccess to users if the user is not a member of the owning program or shared program.

The Not Program Member ACL denies read access to the data in the program,as follows.



ReadWorld

The World accessor denies read access to users if the user is not the member of theowning program or the shared programs.

In Invisible Program rule

The Is Invisible Program (true) –> Invisible Program rule denies read accessto users if the owning program of the data is in the invisible state.

The Invisible Program ACL denies read access to the data in the program, asfollows.

ReadWorld

The World accessor denies read access to program data if the program is in theinvisible state.

In Project rule

The In Project() –> Projects rule grants access to data assigned to projects.This default rule is applied to any object that is assigned to an active project.

The Projects ACL grants read privileges to the data in a project, as follows.

ReadProject Teams

The Project Teams accessor gives all team members read privileges to the data ina project. For example, if the Design, Validation, and Documentation groupsare selected as a project team, the Project Teams accessor grants privileges to allmembers of each group; therefore it is not necessary to use the Group accessor togrant privileges to each group individually.

The project administrator can create or modify project security rules to meet therequirements of a specific project by creating a new named ACL for the project or byadding rules under the In Project condition in the rule tree. Project administratorscan modify rules using Project.

Note Only an administrator with privileges to use Access Manager can change theplacement of the In Project rule in the AM rule tree. They can also modifythe order of the child nodes of the In Project branch of the rule tree.



Is Project Member rule

The Is Project Member(true) –> Project Objects rule specifies whether theuser’s membership in the project is evaluated. This condition is true only when theuser is a current member of the project.

Note The Is Project Member(true) –> Project Objects rule can only bemodified by an administrator using the Access Manager application. Itcannot be modified from the Project application.

The Project Objects ACL grants project administrators and project teamadministrators privileges to modify projects in which they are members. Theseprivileges apply to the project metadata, not to the data assigned to projects.

The ACL is defined as follows.

Accessor Type Accessor ID Read Write Delete Change ChangeOwnership

Owning User

Role ProjectAdministrator

Role Project TeamAdministrator

World

Note You can modify the Project Objects ACL to meet the project accessrequirements at your site.

Is Owned by Program rule

The Is Owned By Program()–>Projects rule grants or denies access to databased on program or project ownership.

The Projects ACL grants read access to the data in the program, as follows.

ReadProject Teams

The Is Owned By Program rule can be configured to enable the exchange ofAerospace and Defense program data between databases. Exchanging program datarequires that the user initiating the import or export is a member of the program towhich the objects being exchanged are assigned.

For information about configuring the Is Owned By Program rule to support theexchange of Aerospace and Defense data, see the Aerospace and Defense SolutionGuide.



Project-level security based on groupsProject-level security is more flexible than group-level security, because data canbe added to and removed from projects without requiring the data properties to bechanged or the ownership of the data to be transferred from one group to another.However, projects can be used in conjunction with groups when developing a securitysolution. Access controls based on projects and groups can be applied in a Multi-SiteCollaboration environment.

Typically, three Access Manager rule conditions are applied to grouped data whenconfiguring project-level security:

• Owning Group(group-name)

Defines security on data based on group ownership and hierarchical groupbehavior, which dictates that subgroups inherit the access controls defined forparent groups.

• Owning Group Has Security(group-name)

Defines security on data based on ownership by groups with a specified securitycategorization, either Internal or External.

• In Project(project-id)

Defines security on the data owned by multiple groups with different securitycategories.

Granting user-based access to project dataTo better understand the examples, you should first understand the rule conditions,access control lists (ACLs), and accessors that comprise the Access Manager rulesused in the examples.

Note Rule conditions and accessors are supplied as part of your Teamcenterinstallation. The ACLs described in this section must be created manually;however, the Projects ACL, which is associated with the In Project rulecondition, is delivered as part of your Teamcenter installation. This ACLgrants read access to project teams.


In Project Specifies a project to which the object must beassigned. The condition is evaluated as beingtrue when the active project to which the objectis assigned matches the project specified for thisrule condition. If you use an empty string as thevalue for this condition, the condition is deemedtrue if the object is assigned to any active project.

In Current Project Specifies the project ID against which the objectis evaluated. The condition is evaluated as beingtrue when the object is in the current activeproject of the logged-on user, and the project IDof the current project matches the value for thiscondition.



ACL Description

project_acl Grants read privileges to the Project Teamsaccessor.

current_project_acl Grants write and delete privileges to the ProjectTeams accessor.

world_read_revoked_acl Denies read access to project data to any userwho is not a project team member.

combo_project_acl Grants read privileges to the Project Teamsaccessor and grants write and delete privilegesto the Current Project Teams accessor.


Current Project Teams Users who are members of current project teams.Applicable only when the object is in the currentproject of the team members and the currentproject is active.

Project Teams Team members in any active project to whichthe object is assigned.

World All users regardless of group, role, or projectmembership.

Configuring user-based access to project data

The ABC Part Company wants to secure their design data to grant members ofproject teams access to the data assigned to a new project. Users who are membersof any project should have read access to the new project data. However, write anddelete access must be restricted to users who are actively working on the new project.There are two options for accomplishing this security objective: option 1 implementsthree rules based on the In Project() condition with corresponding ACLs. Option2 implements one rule based on the In Project() condition and a single ACL thatgrants privileges.

Option 1

In Project() –> project_acl

In Project() –> current_project_acl

In Project() –> world_read_revoked_acl

The In Project() –> project_acl rule is placed higher in the rule tree thanthe In Project() –> current_project_acl rule; therefore, it is evaluated first, asshown in the flowchart.

Note The In Project condition can specify a project. However, in this example thevalue is null; therefore, the object is evaluated for membership in any project.

If the conditions for the In Project() –> project_acl rule are met, the InProject() –> current_project_acl rule is evaluated. The current_project_aclACL defines privileges for a single accessor, Current Project Teams.



If the user accessing the data is not a project team member, the In Project()–> world_read_revoked_acl rule is evaluated. The world_read_revoked_acldenies read access to any user who is not a project team member.

Option 2

In Project() –> combo_project_acl

The In Project() –> combo_project_acl rule is evaluated, as shown in theflowchart,

Note The In Project condition can specify a project. However, in this example thevalue is null; therefore, the object is evaluated for membership in any project.

The combo_project_acl ACL is then evaluated if the object is assigned to a project.The combo_project_acl ACL defines privileges for two accessors, Current ProjectTeams and Project Teams.



Granting role-based access to projectsTo better understand the examples, you should first understand the rule conditions,access control lists (ACLs), and accessors that comprise the Access Manager rulesused in the examples.


In Project Specifies a project to which the object must beassigned. The condition is evaluated as beingtrue when the active project to which the objectis assigned matches the project specified for thisrule condition. If you use an empty string as thevalue for this condition, the condition is deemedtrue if the object is assigned to any active project.



ACL Description

role_based_acl Grants privileges to users based on their role inspecific projects.


Role in Projects of Object Users who have a specific role in one of theprojects of the object. This accessor is affected bythe values set in the AM_PROJECT_MODEpreference. If this preference is not set, only thecurrent active project of the logged on user isevaluated. If the preference is set to true, all ofthe logged on user’s active projects are evaluated.

It is effective only when the user is logged onwith the specified role in the current project, andthe current project is one of the projects assignedto the defined object.

Role in Project Project members with a specific role in a specificproject. This is affected by the values set in theAM_PROJECT_MODE preference.

Configuring role-based access to project data

The ABC Part Company is developing two new products and has created twoprojects, Proj6000 and Proj7000, to organize the work in Teamcenter, and theyplan to implement security based on membership in those projects. Rather thangranting user-based access, they plan to implement access controls based on theroles to which users are assigned.

Users who fill the role of Designer (in the Product Design group) or Checker (inthe Validation group) must have access to the data associated with both projects.Designers require read and write access to the data, while checkers require onlyread access.

Initially, two users are assigned to the project: Lois Parker, who is a designer, andJohn Smith, who is a checker.

There are two options for implementing this security: In Project() –>project_role_acl and In Project() –> project_objects_acl rules.

Tip In this example, Option 1 can result in an ACL with a large number ofentries. Defining access in terms of a specific role within a specific projectcan be cumbersome because many combinations of roles and projects mustbe considered. Option 2, defining access in terms of a specific role in one ofthe projects to which an object is assigned, results in a more manageableACL, because the number of roles is generally smaller than the number ofprojects to which an object is assigned.

Option 1

In Project() –> project_role_acl



Accessor Role

Role in Project Checker in Proj6000

Role in Project Designer in Proj6000

Role in Project Checker in Proj7000

Role in Project Designer in Proj7000

Based on the Project() condition and project_role_acl ACL, the rule is evaluatedas shown in the flowchart.

Note The In Project condition can specify a specific project. However, in thisexample the value is null so the object is evaluated for membership in anyproject.

If the object is assigned to a project, the project_role_acl ACL is applied.The project_role_acl ACL defines privileges for a single accessor, Role in



Project. However, the Role in Project accessor is used in multiple ACEsto reflect both roles in both projects.

Option 2

In Project() –> project_objects_acl

Accessor Role

Role in Projects of Object Checker

Role in Projects of Object Designer

Based on the Project() condition and project_objects_acl ACL, the rule isevaluated, as shown in the flowchart.




If the object is assigned to a project, the project_objects_acl ACL is applied. Theproject_objects_acl ACL defines privileges for a single accessor, Role in Projectsof Object. However, the Role in Projects of Object accessor is used in two ACEsto reflect both roles.

Configuring security when a user is a privileged member of multipleprojects

Frank Jones, a designer at ABC Part Company, is a privileged member of twoprojects, Project A and Project B. According to the default project security rules,Frank, as a privileged team member, is allowed to assign and remove objects fromboth projects.

Project A contains sensitive data that must only be viewed by members of theproject. If Frank assigns an object in Project A to Project B, the members ofProject B can view the sensitive data. To prevent objects in Project A from beingassigned to Project B, the project administrator applies rules and ACLs thatinclude the Assign to project and Remove from project accessor privileges.



The TC_project_validate_conditions preference controls how the Assign toproject and Remove from project accessor privileges are evaluated in conjunctionwith privileged membership validation and can be configured to control access asfollows:

• The user is required to be a privileged project member.

• The user is required to be either a privileged project member or have Assign toproject and/or Remove from project privileges.

• The user is not required to be a privileged project member but must have Assignto project and/or Remove from project privileges.

• The user is required to be a privileged project member and have Assign toproject and/or Remove from project privileges.

Assign to project and Remove from project are object privileges that areassigned to a user on a per-object basis.

The In Project() –> Projects rule restricts the privileges to assign and removeprojects to the owning user.


Accessor Role

Project Teams

Owning User

World

Based on the Project() condition and Projects ACL, the rule is evaluated, asshown in the flowchart.


If the object is assigned to a project, the Projects ACL is applied. The Projects ACLdefines privileges for a three accessors, Project Teams, Owning User, and World.



Configuring security to protect competitive data when multiplesuppliers are members of a common project

To prevent a supplier group from accessing the data of another supplier when bothsuppliers work on the same project, you can define the following rules.

In Project (“project-ID”) –> default_project_acl

Owning Group Has Security (“External”) –> supplier_exclusive_acl

The default_project_acl grants read privileges to all members of the specifiedproject. The supplier_exclusive_acl ACL has the following definition.

Owning Group





The supplier_exclusive_acl ACL grants read privileges to the data of the suppliergroup with an Internal security designation and denies read privileges to groupswith an External security designation.

Implementation considerations for project-level securityYou must consider the following points when implementing project-level security:

• Placement of rules in the Access Manager rule tree.

• Security precedence settings.

• Multi-Site Collaboration import and export.

Placement of rules in the Access Manager rule tree

The In Project() access rule is typically placed above the Owning Group() ruleor Owning Group Has Security() rule in the Access Manager rule tree. Thisplaces a higher level of precedence on access based on the project than on accessbased data ownership.

Set security precedence

You can embed type-level security rules under project-level security rules to give thetype-level security rules higher precedence than the project-level security rules.For example, the project administrator can add a subbranch under the Has Class(Form) rule entry to control access to certain form types that contain sensitive data.The rule for the form type is written as follows.

Has Class(Form)

Has Type(Finance) –> finance_acl

If your site requires that project-level security rules take precedence over type-levelsecurity rules, you must embed project-level security rules under the type-levelsecurity rules. However, Siemens PLM Software does not recommend this practice.

Program security examples

About the program-level security examples

The examples in this section are based on the following rules, which are presented inthe hierarchical order in which they appear in the rule tree:

In Current Program(false) –> Not Current Program



Is Program Member(false) –> Not Program Member


Example 1 — Grant read access to only team members of object’sassigned projectsThe following assumptions apply to this example:

• Item 1 is being accessed by jsmith, who:

o Owns Item 1.

o Is a member of Program 1 and Program 2.

• Item 1 is owned by Program 1 and is not shared with any other projects.

• jsmith’s current program in the Teamcenter session is Program 1.

The In Current Program(false) –> Not Current Program rule is placedhigher in the rule tree than the Is Program Member(false) –> Not ProgramMember rule; therefore, it is evaluated first, as shown in the flowchart.

Because jsmith’s current program is the owning program of Item 1, the IsProgram Member(false) –> Not Program Member rule is evaluated. The NotProgram Member ACL denies read access to any user who is not a member ofthe project.

Because jsmith is a member of the owning program, the In Project() –> Projectsrule is evaluated. The Projects ACL grants read access to members of any projectto which the object is assigned.

Example 2 — Grant read access to all team membersThe following assumptions apply to this example:



• Item 1 is being accessed by jsmith, who:

o Owns Item 1.

o Is a member of Program 1 and Program 2.

• jsmith’s current program in the Teamcenter session is Program 2.

• Item 1 is owned by Program 1 and is not shared with any other programs.

The In Current Program(false) –> Not Current Program rule is placedhigher in the rule tree than the Is Program Member(false) –> Not ProgramMember rule; therefore, it is evaluated first, as shown in the flowchart. jsmith’scurrent program is not the owning program of Item 1; therefore, jsmith is deniedwrite, delete, change, and export privileges.

The Is Program Member(false) –> Not Program Member rule is evaluatednext. Because jsmith is a member, read access to Item 1 is granted and the next rulein the tree In Project() –> Projects is evaluated.

Because Item 1 is assigned to a project/program, the Projects ACL is applied. TheProjects ACL grants read access to the Project Teams accessor. The ProjectTeams accessor gives all team members read privileges to the data in a project. Forexample, if the Design, Validation, and Documentation groups are selected as aproject team, the Project Teams accessor grants privileges to all members of eachgroup; therefore it is not necessary to use the Group accessor to grant privileges toeach group individually. If not, read access is denied.

Example 3 — Grant read access to item to all team members to alldata in project

The following assumptions apply to this example:

• Item 1 is being accessed by bcarter, who:



o Does not own Item 1.

o Is a member of Program 1.

• bcarter’s current program in the Teamcenter session is Program 1.

• Item 1 is owned by Program 1 and is not shared with any other programs.

The In Current Program(false) –> Not Current Program rule is placedhigher in the rule tree than the Is Program Member(false) –> Not ProgramMember rule; therefore, it is evaluated first, as shown in the flowchart.

bcarter’s current program is the owning program of Item 1; therefore, the IsProgram Member(false) –> Not Program Member rule is evaluated.

bcarter is a member of the owning program; therefore, the In Project() –>Projects rule is evaluated and bcarter is granted read access to Item 1.

Example 4 — Grant access to single itemThe following assumptions apply to this example:

• Item 2 is being accessed by mtodd, who:



• mtodd’s current program in the Teamcenter session is Program 1.

• Item 2 is owned by Program 1 and is shared with Program 2.

The In Current Program(false) –> Not Current Program rule is placedhigher in the rule tree than the Is Program Member(false) –> Not ProgramMember rule; therefore, it is evaluated first, as shown in the flowchart below.



mtodd’s current program is not the owning program of Item 2; therefore, mtodd isdenied write, delete, change, and export privileges.

The Is Program Member(false) –> Not Program Member rule is thenevaluated. mtodd is a member of the owning program or a program with which theitem is shared; therefore, the In Project() –> Projects rule is evaluated and theProjects ACL is applied. mtodd is granted read access to Item 2.

Example 5 – Deny read access

The following assumptions apply to this example:

• Item 2 is being accessed by tpenn, who:



• tpenn’s current program in the Teamcenter session is Program 3.

• Item 2 is owned by Program 1 and is shared with Program 2.

The In Current Program(false) –> Not Current Program rule is placedhigher in the rule tree than the Is Program Member(false) –> Not ProgramMember rule; therefore, it is evaluated first, as shown in the flowchart. tpenn’scurrent program is not the owning program of Item 2; therefore, tpenn is deniedwrite, delete, change, and export privileges.

The Is Program Member(false) –> Not Program Member rule is evaluatednext. tpenn is a member of the owning program or a program with which the item isshared; therefore, evaluate the next rule in the tree. tpenn is denied read privileges.



Implementation considerations for program-level securityYou must consider the following points when implementing program-level security:

• Auto assignment of objects to projects.

• Program context.

• Placement of rules in the Access Manager tree.

• Interaction of program and project rules.

• Importing and exporting project data in a Multi-Site Collaboration environment.


Chapter

9 Configuring authorized dataaccess (ADA)

About configuring authorized data access (ADA) . . . . . . . . . . . . . . . . . . . . . . 9-1

Configuring ADA for IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2About configuring ADA for IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Applying Access Manager concepts to IP classified data . . . . . . . . . . . . . . 9-2

About applying Access Manager concepts to IP classified data . . . . . . . 9-2Access Manager rules for restricting access to IP . . . . . . . . . . . . . . . . 9-3Approaches to classification and licensing . . . . . . . . . . . . . . . . . . . . . 9-6Scenarios — Restricting user access using rules and ADA licenses . . . . 9-8Propagating ADA licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Scenario – Implementing ADA for IP based on roles and projects . . . . . . . 9-8About the Implementing ADA for IP based on roles and projects

scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Roles and projects in the Implementing ADA for IP based on roles and

projects scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Rule tree and ACLs in the Implementing ADA for IP based on roles and

projects scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10Evaluation of the rule tree in the Implementing ADA for IP based on roles

and projects scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11Use case 1 — Attempted access with privileges . . . . . . . . . . . . . . . . . 9-11Use case 2 — Unauthorized export . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12Use case 3 — Attempted access without IP license . . . . . . . . . . . . . . . 9-13

Scenario – Implementing ADA for IP based on groups . . . . . . . . . . . . . . . 9-13About the Implementing ADA for IP based on groups scenario . . . . . . 9-13Groups used in the Implementing ADA for IP based on groups

scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14Rule tree and ACLs in the Implementing ADA for IP based on groups

scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14Evaluation of the rule tree in the Implementing ADA for IP based on groups

scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15Use case 1 — Attempted access with privileges . . . . . . . . . . . . . . . . . 9-16Use case 2 — Unauthorized export . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17Use case 3 — Attempted access without valid license . . . . . . . . . . . . . 9-17

Scenario – Implementing ADA for IP at the dataset level . . . . . . . . . . . . . 9-18Scenario – Implementing ADA for IP at the dataset level . . . . . . . . . . 9-18Use case 1 – Using levels of user clearance . . . . . . . . . . . . . . . . . . . . 9-18Use case 2 – Using the super-secret role . . . . . . . . . . . . . . . . . . . . . . 9-20

Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21Access Manager considerations for IP . . . . . . . . . . . . . . . . . . . . . . . . 9-21NX security for classified data for ITAR and IP . . . . . . . . . . . . . . . . . 9-21


Multi-Site Collaboration considerations . . . . . . . . . . . . . . . . . . . . . . . 9-23Basic tasks for configuring and administering ADA for IP data . . . . . . . . . 9-24

About the tasks for configuring and administering authorized data access forIP data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24

Enabling authorized data access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25Configuring logging and blocking in NX . . . . . . . . . . . . . . . . . . . . . . . 9-25Defining IP clearance and classification levels . . . . . . . . . . . . . . . . . . 9-26Assigning IP Admin role and grant IP Admin privileges . . . . . . . . . . . 9-27Assigning users to classify data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27Assigning clearance levels to users . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30Creating IP licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30Assigning classification values to data objects . . . . . . . . . . . . . . . . . . 9-30

Assign an IP classification value to an object . . . . . . . . . . . . . . . . 9-31Associating licenses with data objects . . . . . . . . . . . . . . . . . . . . . . . . 9-32

Attach IP licenses to a data object . . . . . . . . . . . . . . . . . . . . . . . . 9-32

Configuring ADA for ITAR support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32About configuring ADA for ITAR support . . . . . . . . . . . . . . . . . . . . . . . . 9-32Applying Access Manager concepts to technical data subject to ITAR . . . . . 9-33

Basic Access Manager concepts and terms related to ITAR . . . . . . . . . 9-33Access Manager rules for protecting data subject to ITAR . . . . . . . . . . 9-36Scenario – Using rules to control access to data through ADA

licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40About using rules to control access to data through ADA licenses

scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40Use case — Checking for users on named licenses . . . . . . . . . . . . . 9-40Use case — Checking for users on a given type of license . . . . . . . . 9-41Use case — Checking for attached license by name . . . . . . . . . . . . 9-43Use case — Checking user citizenships on attached licenses . . . . . 9-44

Propagating ADA licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46Scenario for implementing ADA for government classified data . . . . . . . . . 9-46ITAR implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-49

Access Manager considerations for ITAR . . . . . . . . . . . . . . . . . . . . . . 9-49NX security for classified data for ITAR and IP . . . . . . . . . . . . . . . . . 9-49Multi-Site Collaboration considerations for ITAR . . . . . . . . . . . . . . . . 9-51

Basic tasks for configuring and administering authorized data access for ITARrestricted data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52

About the tasks for configuring and administering authorized data access forITAR restricted data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52

Enabling authorized data access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53Configuring logging and blocking in NX . . . . . . . . . . . . . . . . . . . . . . . 9-53Defining ITAR clearance and classification levels . . . . . . . . . . . . . . . . 9-54Assigning users to the ITAR Admin role and grant ITAR Admin

privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-55Assigning users to classify data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-55Assigning ADA ITAR attributes to users . . . . . . . . . . . . . . . . . . . . . . 9-58Assigning geographic locations to sites . . . . . . . . . . . . . . . . . . . . . . . 9-59Assigning nationality to groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59Creating ITAR licenses (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60Assigning government classification values to data objects . . . . . . . . . 9-60

Assign a government classification value to an object . . . . . . . . . . 9-60Associating licenses with data objects . . . . . . . . . . . . . . . . . . . . . . . . 9-61

Attach ITAR licenses to a data object . . . . . . . . . . . . . . . . . . . . . . 9-61Customizing Access Manager rules . . . . . . . . . . . . . . . . . . . . . . . . . . 9-61

Security Administration Guide PLM00101 I

Chapter

9 Configuring authorized dataaccess (ADA)

About configuring authorized data access (ADA)Authorized data access (ADA) is a security solution that complements otherTeamcenter security features, such as Access Manager rules and access control lists(ACLs). Authorized data access controls sensitive data through the use of dataclassification, user clearance, and authorizing documents. When users or groupsattempt to access classified data in Teamcenter, their clearance level is evaluatedagainst the classification of the object based on Access Manager rules. If the useror group clearance level is equal to or greater than the classification on the object,access is granted.

There are three types of licenses for authorized data access:

• IP license

Grants discretionary access to data for a specific user for a specific period of time.

You can configure the rule tree to check for a valid IP license associated with anobject and user. If found, other access checks are bypassed.

• Exclude license

A mechanism for denying users access to data for a specific period of time.

You can configure the rule tree to check for a valid execution license associatedwith an object and user. If found, other access checks are bypassed.

• ITAR (International Traffic in Arms) license

Grants discretionary access to specific users or groups to workspace objects withInternational Traffic in Arms Regulations (ITAR) classifications for a specifiedperiod of time. Typically it is used to grant access for a specific time periodto citizens of other countries, United States (U.S.) citizens physically locatedoutside the U.S., or organizations that are named in an effective TechnicalAssistance Agreement (TAA) through an ITAR license.

The ADA concepts described in the previous paragraphs assume that data is storedin and accessed from within the Teamcenter environment. You can also configurelogging and menu suppression (blocking) to be applied when classified data is loadedin Teamcenter Integration for NX. Logging provides an audit of actions performed onexporting data, and blocking suppresses NX menus to prevent geometric data frombeing exported outside of the NX/Teamcenter environment.


Chapter 9 Configuring authorized data access (ADA)

Note In this context, export refers to performing an operation, such as creatinga copy or printing data, that moves the data outside of the Teamcenterenvironment.

As a user with an ADA administrator role (IP Admin or ITAR Admin), you usethe ADA License application to create and maintain licenses. Once created, accessis either granted or denied to users and groups by associating the license directlywith the data object.

Configuring ADA for IP

About configuring ADA for IP

Limited-time exceptions to allow access to data that is under authorized data access(ADA) control can be granted to specific users through an authorizing document(intellectual property (IP) license). Conversely, access to classified data can be deniedto specific users for a period of time through the use of exclude licenses.

Note Securing data through an IP license only restricts it so it cannot be seenby users. If the data is visible, nothing prevents a user from printing orsaving a copy.

Applying Access Manager concepts to IP classified data

About applying Access Manager concepts to IP classified data

The following concepts are fundamental to understanding how to apply AccessManager concepts to intellectual property (IP) data.

Concept Description

IP clearance IP clearance applies to a specific userand specifies the level of access the userhas to sensitive (classified) information.The clearance value assigned to theuser must match a value defined in theIP_level_list_ordering preference.

IP classification IP classification applies to data andspecifies the clearance level requiredfor users to access the data. Theclassification value assigned to an objectmust match a value defined in theIP_level_list_ordering preference.

IP licenses IP licenses grant discretionary accessto data for a specific user or group fora specific period of time. The rule treecan be configured to check for a valid IPlicense associated with an object anduser. If found, other access checks arebypassed.


Configuring authorized data access (ADA)

Concept Description

Exclude licenses Exclude licenses are a mechanismfor denying users access to data for aspecific period of time. The rule tree canbe configured to check for a valid excludelicense associated with an object anduser. If found, other access checks arebypassed.

IP Admin privileges IP Admin privileges must be explicitlygranted and denied to prevent usersfrom gaining unauthorized access to IPdata.

IP Classifier privileges IP Classifier privilege lets usersclassify data without having all theprivileges of the IP Admin. It must beexplicitly granted and denied to preventusers from gaining unauthorized accessto IP data.

Access Manager rules for restricting access to IP

Access Manager rules allow you to establish access controls on intellectual property(IP) data. The following rule conditions and accessor types are used to configure IPdata access rules.

For a list of recommended rules and ACLs for managing ADA licenses, seeAuthorized Data Access License Guide.

Condition Value Description

User Has IP Clearance Specific clearance valuesthat can be prefixed by thefollowing operators:

“>”“>=”“<”“<=”=

Validates the user’sclearance level againstthe value specified for thecondition.

The operators can beused without a clearancevalue; the user’s clearanceis compared to the IPclassification attribute ofthe object based on thespecified operator.

Note If the data isnot IP classified,the User HasIP Clearancecondition isevaluated as beingtrue, regardless ofwhether or not theuser is assigned aclearance level.




Has IP Classification Specific IP classificationattribute values thatcan be prefixed by thefollowing operators:

“>”“>=”“<”“<=”=

Validates the IPclassification attributevalue of the object againstthe value specified for thecondition.

The operators can beused without a clearancevalue; the IP classificationattribute of the object iscompared to the user’sclearance level based onthe specified operator.

Note If the object has noIP classificationattribute value,this rule does notapply.

Has No IPClassification

Matches if the object hasa null value for the IPclassification attribute.

User Is IP Licensed true or false If set to true verifiesthe existence of a valid(not expired) IP licenseattached to the objectbeing evaluated thatnames the current user ortheir group as a licensee.

User Is Excluded true or false Specifies whether the useror group is cited in a validexclude license attachedto the workspace objectbeing evaluated.

User In Attached IPLicense

Any or All Checks whether the useris on any or all IP licensesattached to the workspaceobject being evaluated.

• If set to Any, the useris on at least one IPlicense.

• If set to All, the useris on all IP licenses.

For more information, seeScenario – Using rulesto control access to datathrough ADA licenses.




Has Named IP License License ID Checks whether aworkspace object has anIP license of the specifiedname. It does not check ifa user is on the license.


User In Named IPLicense

License ID Checks whether a useris on an IP license of thespecified name. It doesnot check if the license isattached to the workspaceobject being evaluated.


User In AttachedExclude License

Any or All Checks whether the useris on any or all excludelicenses attached to theworkspace object beingevaluated.

• If set to Any, theuser is on at least oneexclude license.

• If set to All, theuser is on all excludelicenses.


Has Named ExcludeLicense

License ID Checks whether aworkspace object hasan Exclude license of thespecified name. It does notcheck if a user is on thelicense.





User In Named ExcludeLicense

License ID Checks whether a user ison an exclude license ofthe specified name. It doesnot check if the license isattached to the workspaceobject being evaluated.



User Excluded Current user (or their group) that iscited on an unexpired exclude licenseassociated with the object.

User IP Licensed User is cited in any current IP licenseassociated with the selected object eitherdirectly or by membership in a groupcited by the license.

User IP Unlicensed User is not cited in any current IP licenseassociated with the selected object.

User Under IP Clearance The user’s IP clearance is below thelevel required by the object. Thisaccessor is typically used to revokeaccess and is only applicable when theIP clearance on the user and the IPclassification on the object come from acommon multilevel scheme defined bythe IP_level_list_ordering preference.

User has IP Clearance Compares the user’s IP clearance withthe object’s IP classification and testswhether the user has clearance above,below, or equal to that required to accessthe object.

User Over IP Clearance The user’s IP clearance is over the levelrequired by the object. This accessoris typically used to grant access and isonly applicable when the IP clearanceon the user and the IP classificationon the object come from a commonmultilevel scheme defined by theIP_level_list_ordering preference.

Approaches to classification and licensing

Classification and licensing can be implemented at different levels within theobject model hierarchy. This section describes three approaches to licensing andclassification for controlling access to the datasets that contain geometry data.



Classifying, licensing, and performing the rule check at the item level

Applying classification and licensing to the item object and performing the rule checkat the item level allows you to control access to the item and all related informationbeneath that item in the object hierarchy, because licensing and classificationattributes are inherited from parent items in the hierarchy. While this methodachieves the goal of protecting the geometry data, it prevents unauthorized usersfrom viewing the metadata, such as items, item revisions, and BOM view revisions.

Classifying and licensing at the item level but performing the rule check atthe dataset level

Applying classification and licensing at the item level but performing the rulecheck at the dataset level is a more flexible alternative. For example, assume thatlicensing and classification are applied at the item level and the Access Managerrule is written to check the classification and licensing when the object being accessis a UGMASTER dataset.

This approach achieves the goal of preventing unauthorized access to the geometrydata while allowing you to apply classification and licensing at a high level in thehierarchy, which is more efficient than applying classification and licensing to eachdataset individually. However, this approach also allows users without clearance toview the metadata associated with the geometry.

The following example shows how the rule tree might be configured to supportclassification and licensing at the item level with rule checking performed at thedataset level:

Has Class(User) –> IPAdminACL

Has Type(UGMaster)

Is Ex Licensed(True) –> NoAccessACL

User Is IP Licensed(True) –> Consumer ACL

Has Class(POM_object) –> ProjRoleACL

User Is IP Licensed(False) –> NoAccessACL

User Has IP Clearance(>=) –> ProjRoleACL

Has Type(UGPart)

Is Ex Licensed(True) –> NoAccessACL

User Is IP Licensed(True) –> Consumer ACL

Has Class(POM_object) –> ProjRoleACL





Classifying, licensing, and performing rule checks at the dataset level

Classifying and licensing at the dataset level does not allow inheritance ofclassification and licensing properties from parent items and item revisions;therefore, these attributes must be applied to each individual dataset. While thisis a valid approach to classification and licensing, Siemens PLM Software does notrecommend this approach.

Scenarios — Restricting user access using rules and ADA licenses

To learn about restricting user access to data using rules and Authorized DataAccess (ADA) licenses together, see the use cases in Scenario – Using rules to controlaccess to data through ADA licenses. The use cases use ITAR examples but there arecorresponding rule conditions for managing access to data using IP licenses, so theconcepts shown for ITAR apply to IP as well.

Propagating ADA licenses

Authorized data access (ADA) licenses are propagated to related objects, basedon relation propagation rules when the licenses are attached to workspaceobjects. This behavior is dependent on the value (true by default) specified forthe ADA_allow_license_propagation preference. Also, ADA licenses can bepropagated to a new object when the object is created using the Save As command.License propagation is determined by relation propagation rules and the valuesspecified for the ADA_saveas_propagated_license_types preference.

For more information about ADA license propagation, see the Authorized DataAccess License Guide.

For information about the ADA_allow_license_propagation andADA_saveas_propagated_license_types preferences, see the Preferences andEnvironment Variables Reference.

Scenario – Implementing ADA for IP based on roles and projects

About the Implementing ADA for IP based on roles and projects scenario

In this scenario, Access Manager rules, data classification, and intellectual property(IP) licensing are used to control access to IP data based on roles and projects. Inaddition, use cases illustrate how the rule tree is evaluated for different users withvarying clearance levels, roles, project membership, and IP licensing.

Roles and projects in the Implementing ADA for IP based on roles and projectsscenario

The examples in this scenario assume that the ABC Part Company uses roles andprojects to control access to data. Roles represent functional areas to which users areassigned, and projects organize data by work program.

ABC Part Company uses the following Teamcenter groups: Design, Engineering,and Test Engineering.

Work is divided into the following projects: Project1, Project2, and Project3.Project1 is a design project that contains some sensitive data.



Project2 is an engineering project that does not contain sensitive data; however,some members of Project2 require access to specific sensitive files in Project1and Project3.

Project3 is a test engineering project that does not contain sensitive data; however,some members of Project3 require access to specific sensitive files in Project1and Project2.

The following table maps data requirements for these groups and projects.

Design group Engineering group Test Engineering group

Project1 All design datais assigned toProject1, and allusers in theDesigngroup are membersof Project1.

Access can begranted based onproject membershipor by using IPlicenses.

A subset of engineering data isassigned to Project1. Specificusers in the Engineeringgroup are granted access tospecific data in Project1 usingIP licenses.

A subset of test data is assigned to Project1. Specificusers in the Test Engineering group are grantedaccess to specific data in Project1 using IP licenses.

Project2 A subset of designdata is assigned toProject2. Specificusers in theDesigngroup are grantedaccess to specificdata using IPlicenses.

All engineering data isassigned to Project2, and allusers in the Engineeringgroup are members ofProject2.

Access can be granted basedon project membership or byusing IP licenses.

A subset of test data is assigned to Project2. Specificusers in the Test Engineering groups are grantedaccess to specific data in Project2 using IP licenses.

Project3 A subset of designdata is assigned toProject3. Specificusers in theDesigngroup are grantedaccess to specificdata using IPlicenses.

A subset of engineering data isassigned to Project3. Specificusers in the Engineeringgroup are granted access tospecific data using IP licenses.

All test data is assigned to Project3, and all users inthe Test Engineering group are members of Project3.

Access can be granted based on project membership orby using IP licenses.

In addition to the group and project structure employed by ABC Part Company, thefollowing assumptions are made in the examples in this section:

• The value of the AM_PROJECT_MODE preference is False.

Note If this preference is not set, or if it is set to False, only the current activeproject of the logged on user is evaluated. If the preference is set to true,all of the logged on user’s active projects are evaluated.

• Data is associated with one group and assigned to one project.

• Sensitive data is assigned a classification value. No assumptions are made aboutat what level in the data model hierarchy the data is classified or the IP licenseis attached.

Siemens PLM Software recommends classifying and licensing at the item level.

• Classified data is contained in .prt files associated with UGMASTER datasets.



• Teamcenter metadata associated with the classified data must be available toproject members even if they do not have clearance to access the geometry dataor an IP license that grants them access. Membership in the project is sufficientto allow access to the metadata.

• Users requiring access to classified data are assigned a clearance level thatequals or exceeds the classification value of the data that they need to access.Users must also be a member of at least one of the projects with which the datais associated; otherwise, they must be granted access by IP licensing.

Rule tree and ACLs in the Implementing ADA for IP based on roles and projectsscenario

The Teamcenter administrator at ABC Part Company has created the IPAdminACLACL, ConsumerACL ACL, the NoAccessACL ACL, and the ProjRoleACL ACLas part of their security implementation.

The IPAdminACL ACL used in the rule tree is defined, as follows.

Role IP Admin

World

The ConsumerACL ACL used in the rule tree is defined, as follows.

Otherprivileges

Role Consumer

The NoAccessACL ACL used in the rule tree is defined, as follows.

Otherprivileges

World Temp Part Author

The ProjRoleACL ACL used in the rule tree is defined, as follows.

Otherprivileges

Role in Projectsof Object

Team Author

Role in Projectsof Object

Temp Part Author

Using the IPAdminACL ACL, ConsumerACL ACL, NoAccessACL ACL, and theProjRoleACL ACL, the ABC Part Company has implemented the following rules inthe Access Manager rule tree:

Has Bypass(true) –> ByPassACL




Has Type(UGMaster)

User Is IP Licensed(True) –> ConsumerACL

Has Class(Pom_object) –> ProjRoleACL



<subsequent-rules>

Evaluation of the rule tree in the Implementing ADA for IP based on roles andprojects scenario

When a user attempts to access data in Teamcenter, the rules in the tree areevaluated as follows:

1. If the user has By Pass set, the ByPassACL ACL determines access privilegesto the object.

This is a high-level rule that grants system administrator privileges.

2. The Has Type(UGMaster) condition is evaluated.

If the data object type is UGMaster, the evaluation proceeds down the ruletree, as follows:

• The User Is IP Licensed(true) condition is evaluated to determine if theuser is cited in a valid IP license for the data object.

If so, the Has Class(POM_object) –> ProjRoleACL subbranch isevaluated. If the Has Class(POM_object) –> ProjRoleACL rule applies,the ProjRoleACL is applied.

If the Has Class(POM_object) –> ProjRoleACL rule does not apply, theConsumerACL ACL from the parent rule, User Is IP Licensed(True) –>ConsumerACL, is applied.

• If the User Is IP Licensed(True) –> ConsumerACL rule does notapply, the evaluation continues to the User Is IP Licensed(False) –>NoAccessACL branch.

If the user, or their group, is not cited in a valid IP license, the User Has IPClearance(>=) –> ProjRoleACL subbranch is evaluated.

If the user’s clearance is greater than or equal to the classification level ofthe object, the ProjRoleACL ACL is applied. If the user’s clearance level isless than the classification level of the object, the NoAccessACL ACL fromthe parent rule, User Is IP Licensed(False) –> NoAccessACL, is applied.

Use case 1 — Attempted access with privileges

In this use case, the rule tree is evaluated when Robert Smith attempts to accessPart1 in the database. Robert requires read, write, and import privileges tocomplete his task.

Robert Smith has the following clearance level, role, and project membership.



User Clearance level Role Project Current project

smithr 2 Team author in Project1 Project1 Project1

In addition, Part1 is a UGMaster dataset. The classification level of Part1 is 1,and there are no valid IP licenses associated with Part1 that cite Robert Smithas an authorized user.

Given this information, the rule tree is evaluated as follows:

1. The Has Type(UGMaster) condition is evaluated, and the evaluation proceedsdown the tree.

2. The User Is IP Licensed(true) –> ConsumerACL rule is evaluated.

There is no valid IP license on Part1 citing Robert Smith as an authorized user;therefore, the evaluation proceeds down the tree.

Note Because the User Is IP Licensed(true) –> ConsumerACL isevaluated as false, the Has Class(Pom_object) –> ProjRoleACLsubbranch is not evaluated.

3. The User Is IP Licensed(False) –> NoAccessACL rule is evaluated.

Robert Smith is not IP licensed; therefore, the User Has IP Clearance(>=) –>ProjRoleACL subbranch is evaluated. The rule evaluates to true, becauseRobert Smith’s clearance level is 2 and the classification level of Part1 is 1;therefore, the ProjRoleACL ACL is applied.

At this point, the rule tree evaluation has determined that the user has sufficientprivileges to perform the requested operation and no further rule tree processingis required.

Use case 2 — Unauthorized export

In this use case, the rule tree is evaluated when Jane Davis attempts anunauthorized export operation on Part1.

Jane Davis has the following clearance level, role, and project membership.

User Clearance level Role Role in project Project Current project

davisj 1 Consumer Team Author inProject1

Project1 Project1

In addition, Part1 is a UGMaster dataset. The classification level of Part1 is 2, andJane Davis is cited by a valid IP licenses associated with Part1.




There is a valid IP license on Part1 citing Jane Davis as an authorizeduser; therefore, the Has Class(Pom_object) –> ProjRoleACL subbranch isevaluated.



3. The Has Class(Pom_object) –> ProjRoleACL rule evaluates to true, and theProjRoleACL ACL is applied.

However, Jane Davis does not fill a role in Project2 to which Part1 is assigned;therefore, none of the privileges of the ProjRoleACL ACL are applied and theevaluation proceeds down the rule tree.

4. The User Is IP Licensed(False) –> NoAccessACL is evaluated.

Jane Davis is IP licensed; therefore, the NoAccessACL ACL is not appliedand the subbranch is not evaluated.

At this point, the rule tree evaluation has determined that the user does nothave sufficient privileges to perform the export operation and no further ruletree processing is required.

Use case 3 — Attempted access without IP license

In this use case, the rule tree is evaluated when Doug Abbott, who has a role in theproject, attempts to access Part1 without appropriate clearance or a valid IP license.

Doug Abbott has the following clearance level, role, and project membership.

User Clearance level Role in project Project

abbottd 1 Temp Part Author in Project2 Project2

In addition, Part1 is a UGMaster dataset. The classification level of Part1 is 2,and it is assigned to Project2. Doug Abbott is not cited by a valid IP licensesassociated with Part1.




There is not a valid IP license on Part1 citing Doug Abbott as an authorizeduser; therefore, the ConsumerACL ACL is not applied, and the HasClass(Pom_object) –> ProjRoleACL subbranch is not evaluated.

3. The User Is IP Licensed(false) –> NoAccessACL rule is evaluated.

This condition is true; therefore, the User Has IP Clearance(>=) –>ProjRoleACL subbranch is evaluated.

Doug Abbott’s clearance level is 1, and the classification of the part is 2; therefore,the NoAccessACL ACL from the parent branch, User Is IP Licensed(false)–> NoAccessACL, is applied and access is denied.

Scenario – Implementing ADA for IP based on groups

About the Implementing ADA for IP based on groups scenario

In this scenario, Access Manager rules, data classification, and intellectual property(IP) licensing are used to control access to IP data based on groups. In addition,use cases illustrate how the rule tree is evaluated for different users with varyingclearance levels, roles, project membership, and IP licensing.



Groups used in the Implementing ADA for IP based on groups scenario

The examples in this section assume that the ABC Part Company uses groups,which organize users into functional clusters, to control access to data. ABC PartCompany uses the following Teamcenter groups: Design, Engineering, and TestEngineering.

The Design group owns both sensitive data and nonsensitive data. Only userswho should be allowed access to the sensitive data are granted membership in theDesign group. Other users who require access are granted limited-time accessprivileges through an IP license.

The Engineering group owns both sensitive and nonsensitive data. Only userswho should be allowed access to the sensitive data are granted membership in theEngineering group. Other users who require access are granted limited-time accessprivileges through an IP license.

The Test Engineering group owns both sensitive data and nonsensitive data. Onlyusers who should be allowed access to the sensitive data are granted membershipin the Test Engineering group. Other users who require access are grantedlimited-time access privileges through an IP license.

Other assumptions:

• Classification values are applied to sensitive data, and no assumption is madeabout where in the class hierarchy the information is classified. However,Siemens PLM Software recommends classifying data at the item level of theobject model hierarchy.

• Classified data is contained in a UGMaster dataset.

• Teamcenter metadata associated with sensitive data must be available to usersin the owning group, even if they do not have the clearance required to accessthe classified data or an IP licensing granting access to the data. Membership inthe owning group must be sufficient to establish to right to view metadata.

• Users who require access to classified data are either members of the owninggroup or are assigned an IP clearance level greater than or equal to theclassification of the data to which they require access. Alternatively, users canbe granted access using an IP license.

Rule tree and ACLs in the Implementing ADA for IP based on groups scenario

The Teamcenter administrator at ABC Part Company has created the IPAdminACLACL, ConsumerACL ACL, the GroupRoleACL ACL, and the NoAccessACL ACLas part of their security implementation.


Role IP Admin

World

The ConsumerACL ACL used in the rule tree is defined, as follows.



Otherprivileges

Role Consumer

The NoAccessACL ACL used in the rule tree is defined, as follows.

Otherprivileges

World Temp Part Author

The GroupRoleACL ACL used in the rule tree is defined, as follows.

Otherprivileges

Role in OwningGroup

Team Author

Role in OwningGroup

Temp Part Author

Using the IPAdminACL ACL, ConsumerACL ACL, NoAccessACL ACL, andthe GroupRoleACL ACL, the ABC Part Company has implemented the followingrules in the Access Manager rule tree:

Has Bypass(true) –> ByPassACL


Has Type(UGMaster)

User Is IP Licensed(True) –> ConsumerACL

Has Class(Pom_object) –> GroupRoleACL



<subsequent-rules>

Evaluation of the rule tree in the Implementing ADA for IP based on groupsscenario

When a user attempts to access data in Teamcenter, the rules in the tree areevaluated as follows:

1. If the user has By Pass set, the ByPassACL named ACL determines accessprivileges to the object.

This is a high-level rule that grants system administrator privileges.

2. The Has Type(UGMaster) condition is evaluated.

If the data object type is UGMaster, the evaluation proceeds down the ruletree, as follows:

• The User Is IP Licensed(true) condition is evaluated to determine if theuser is cited in a valid IP license for the data object.



If so, the Has Class(POM_object) –> GroupRoleACL subbranch isevaluated and if valid, theGroupRoleACL ACL is applied. If the subbranchis not valid, the ConsumerACL ACL from the parent rule, User Is IPLicensed(true) –> ConsumerACL, is applied.

• If the User Is IP Licensed(true) condition is not met, the User IsIP Licensed(false) condition is evaluated, and the User Has IPClearance(>=) –> GroupRoleACL subbranch is evaluated.

If the user’s clearance is greater than or equal to the classification levelof the object, the GroupRoleACL ACL is applied. If the subbranch isnot valid, the NoAccessACL ACL from the parent branch, User Is IPLicensed(false) –> NoAccessACL, is applied.

Use case 1 — Attempted access with privileges

In this use case, the rule tree is evaluated when Robert Smith attempts to accessPart1 in the database. Robert requires read, write, and import privileges tocomplete his task.

Robert Smith has the following clearance level, role, and group membership.

User Clearance level Role in Group Group

smithr 2 Team Author Design

In addition, Part1 is a UGMaster dataset that is owned by the Design group. Theclassification level of Part1 is 1, and there are no valid IP licenses associated withPart1 that cite Robert Smith as an authorized user.




There is no valid IP license on Part1 citing Robert Smith as an authorized user;therefore, the evaluation proceeds down the tree.

Note The User Is IP Licensed(true) –> ConsumerACL rule is evaluatedas false; therefore, the Has Class(Pom_object) –> GroupRoleACLsubbranch is not evaluated.

3. The User Is IP Licensed(False) –> NoAccessACL rule is evaluated.

Robert Smith is not IP licensed; therefore, the User Has IP Clearance(>=) –>GroupRoleACL subbranch is evaluated.

The rule evaluates to true, because Robert Smith’s clearance level is 2 andthe classification level of Part1 is 1. The GroupRoleACL ACL grants Read,Write, and Import privileges to the user.

At this point, the rule tree evaluation has determined that the user has sufficientprivileges to perform the requested operation and no further rule tree processing isrequired.



Use case 2 — Unauthorized export

In this use case, the rule tree is evaluated when Jane Davis attempts anunauthorized export operation on Part1.

Jane Davis has the following clearance level, role, and group membership.

UserClearancelevel Role Role in group Group

davisj 1 Consumer Team Author in Design group Design

In addition, Part1 is a UGMaster dataset owned by the Engineering group.The classification level of Part1 is 2, and Jane Davis is cited by a valid IP licenseassociated with Part1.




There is a valid IP license on Part1 citing Jane Davis as an authorized user;therefore, the HasClass(Pom_object) –> GroupRoleACL subbranch isevaluated.

The HasClass(Pom_object) –> GroupRoleACL rule evaluates to true, andthe GroupRoleACL ACL is applied.

However, Jane Davis does not fill a role in the Engineering group by whichPart1 is owned; therefore, none of the privileges of the GroupRoleACL ACLare applied, and the evaluation proceeds down the rule tree.

At this point, the rule tree evaluation has determined that the user does nothave sufficient privileges to perform the export operation and no further ruletree processing is required.

Use case 3 — Attempted access without valid license

In this use case, the rule tree is evaluated when Doug Abbott, who has a role in theowning group, attempts to access Part1 without appropriate clearance or a validIP license.

Doug Abbott has the following clearance level, role, and group membership.

User Clearance level Role in group Group

abbottd 1 Temp Part Author in Engineeringgroup

Engineering

In addition, Part1 is a UGMaster dataset. The classification level of Part1 is 2,and it is owned by the Engineering group. Doug Abbott is not cited by a valid IPlicense associated with Part1.






There is not a valid IP license on Part1 citing Doug Abbott as an authorizeduser; therefore, the ConsumerACL ACL is not applied and the HasClass(Pom_object) –> GroupRoleACL subbranch is not evaluated.

The evaluation continues down the tree.

3. The User Is IP Licensed(false) –> NoAccessACL rule is evaluated.

This condition is true; therefore, the User Has IP Clearance(>=) –>GroupRoleACL subbranch is evaluated.

Doug Abbott’s clearance level is 1 and the classification of the part is 2; therefore,the rule is not valid.

The NoAccessACL ACL from the parent rule, User Is IP Licensed(false) –>NoAccessACL, is applied and access is denied.

Scenario – Implementing ADA for IP at the dataset level

Scenario – Implementing ADA for IP at the dataset level

The following use cases illustrate how Access Manager rules can be configured tocontrol access to classified intellectual property (IP) data. Both examples assumethat the dataset is the object that is classified and that the item or item revision andany corresponding BOM views are viewable by any user.

Use case 1 – Using levels of user clearance

In this example, the ABC Part Company is implementing rules to secure sensitivedata. To do this, they have established two levels of user clearance, secret andsuper secret, and one level of IP (data) classification, secret. In addition, they havecreated an IP license, lic 1 that names Robert Smith as an authorized user. Theyhave applied these clearances and classifications as follows.

User Clearance level

Robert Smith (smithr) None

Jane Davis (davisj) secret

Peter Taylor (taylorp) super secret

Dataset ID Classification level License

ABC0001 None None

ABC0002 secret None

ABC0003 secret license 1

Based on the clearance, classification, and licensing, ABC Part Company hasimplemented three access control lists (ACLs): IPAdminACL ACL, IPACL ACL,and NoIPACL ACL.




Role IP Admin

World

The IPACL ACL is defined as follows.

Owning User

IP Licensed

User under clearance

User over clearance

Role in Owning Group IP Admin

World

The NoIPACL ACL is defined as follows.


World

The IPACL ACL and the NoIPACL ACL are used in the following rules:

Has Class (POM_object)

Has Bypass (true) –> Bypass

Has IP Classification() –> IPACL

Has No IP Classification() –> NoIPACL

Has Class(User) -> IPAdminACL

Has Class(POM_object) –> System objects

In addition to the clearance levels, classification levels, ACLs, and rules, ABC PartCompany can set the TC_session_clearance preference to provide one of threelevels of monitoring: unset, blocking, or logging. The Unmanage privilegecan be granted to allow users to circumvent the blocking, if applicable. For moreinformation about session clearance, see Configuring logging and blocking in NX.

The results of the security implementation described in this section are displayedin the following table. The table lists results for each user, at each level of sessionclearance monitoring, for each dataset.



SessionClearance User Clearance Dataset Classification License Read Write

IPLogged

User canunmanage Unmanage

block smithr none ABC0001 none none Y Y N Y Y

block davisj none ABC0001 none none Y Y N Y Y

block taylorp none ABC0001 none none Y Y N Y Y

block smithr none ABC0002 secret none N N/A N/A N/A N/A

block davisj secret ABC0002 secret none Y Y Y N N

block taylorp super secret ABC0002 secret none Y Y Y Y Y

block smithr none ABC0003 secret lic 1 Y Y Y N N

block davisj secret ABC0003 secret lic 1 Y Y Y N N

block taylorp super secret ABC0003 secret lic 1 Y Y Y Y Y

log smithr none ABC0001 none none Y Y N Y Y

log davisj secret ABC0001 none none Y Y N Y Y

log taylorp super secret ABC0001 none none Y Y N Y Y

log smithr none ABC0002 secret none N N/A N/A N/A N/A

log davisj secret ABC0002 secret none Y Y Y Y Y

log taylorp super secret ABC0002 secret none Y Y Y Y Y

log smithr none ABC0003 secret lic 1 Y Y Y Y Y

log davisj secret ABC0003 secret lic 1 Y Y Y Y Y

log taylorp super secret ABC0003 secret lic 1 Y Y Y Y Y

unset smithr none ABC0001 none none Y Y N Y Y

unset davisj secret ABC0001 none none Y Y N Y Y

unset taylorp super secret ABC0001 none none Y Y N Y Y

unset smithr none ABC0002 secret none N N/A N/A N/A N/A

unset davisj secret ABC0002 secret none Y Y N Y N

unset taylorp super secret ABC0002 secret none Y Y N Y Y

unset smithr none ABC0003 secret lic 1 Y Y N Y Y

unset davisj secret ABC0003 secret lic 1 Y Y N Y Y

unset taylorp super secret ABC0003 secret lic 1 Y Y N Y Y

Use case 2 – Using the super-secret role

In this example, the ABC Part Company is implementing rules to secure sensitivedata using a variation on the security scheme implemented in use case 1.

To do this, they have established one level of user clearance, secret, and they havecreated a new role, super-secret. (The super-secret role provides functionalityequivalent to the super secret user clearance level in use case 1.)

Based on this clearance level and role, ABC Part Company has implemented theIPACL ACL, as follows.



Owning User

IP Licensed

User under clearance

Role in Owning Group super-secret


World

The difference between the definition of the IPACL ACL in this use case and theACL in use case 1 is that the User Over Clearance accessor is replaced with theRole in Owning Group(super-secret) accessor.

The benefit of use case 2 is that it leaves no possibility of a higher level of securitybeing applied to the data. It also enables you to limit the use of the super-secretrole to a single group or project.

In both use cases, using Access Manager to assign unmanage privileges enables NXto read the blocking property.

Implementation considerations

Access Manager considerations for IP

Placement of rules in the Access Manager rule treeAccess Manager implicitly grants access privileges to data unless privileges areexplicitly revoked; therefore, rules to identify users with IP clearance or licenseshould be placed high in the rule tree. For example, placing IP rules higher than theHas Object ACL condition prevents users from retaining privileges to somethingthat is later classified. If neither IP-related condition applies, the rule tree isevaluated and data access privileges are determined by other factors, such as projectmembership or object ownership, as the rule tree is evaluated.

Authorized data access rule precedence for ITAR and IPWhen both ITAR and IP access rules are in force at a site, ITAR rules must takeprecedence over IP rules. Therefore, you must place ITAR rules higher in the ruletree than IP rules.

NX security for classified data for ITAR and IP

When operating in Teamcenter Integration for NX mode, Teamcenter providessecurity metadata to NX. This metadata is computed using the user and dataproperties and directs how NX behavior is modified when processing secure data.Security metadata is constant in NX, even if the information changes in Teamcenter.For example, if a user is granted access to data in NX based on a license, and thelicense expires while the data is open in NX, the expiration is not recognized by NXuntil the user attempts to save the data back to Teamcenter, at which point theoperation fails because the user’s license has expired.



Authorized data access logging and blocking supports NX datasets as well asnon-NX datasets that can be translated into a part file, including JT, Solid Edge,and CATIA data.

The following NX operations are affected when logging and blocking areimplemented.

OperationBlocked andlogged Blocked

File→Save As X

File→Print X

File→Plot X

File→Send to Package File X

File→Export→Part X

File→Export→Parasolid X

File→Export→User DefinedFeature

X

File→Export→CGM X

File→Export→STL X

File→Export→Polygon File X

File→Export→Author HTML X

File→Export→TeamcenterVisualization

X

File→Export→VRML X

File→Export→PNG X

File→Export→JPEG X

File→Export→GIF X

File→Export→TIFF X

File→Export→BMP X

File→Export→XWD X

File→Export→IGES X

File→Export→STEP203 X


File→Export→DXF/DWG X

File→Export→2D exchange X

File→Export→Heal Geometry X

File→Export→V4 Catia X


File→Export drawings toTeamcenter

X

File→Interoperate




File→Collaborate X

Edit→Copy Display X

View→Visualization→High QualityImage

X

View→Visualization→CreateAnimation

X

Tools→NX Manager→ExportAssembly

X

Tools→NX Manager→Save OutsideTeamcenter

X

Tools→Part Families Create X

Tools→Part Family Update X

Assemblies→Components→CreateNew

X

Assemblies→Components→AddExisting

X

Assemblies→Components→SubstituteComponent

X

Assemblies→Components→PartFamily Update

X

Assemblies→Components→CreateNew Parent

X

Assemblies→Cloning→CreateClone Assembly

X

Edit→Paste [Pasting of acomponent]

X

Dragging a drawing template ontoa part

X

For more information about configuring logging and blocking, see Configuringlogging and blocking in NX.

Multi-Site Collaboration considerations

Take care when sharing classified data with other Teamcenter sites.

Caution It is possible that when importing a mixture of classified and unclassifieddata, the user who performs the import could view data to which they donot have clearance. Teamcenter tests for privileges when importing data,but the system does not read the classification attribute until the objecthas been reassembled and saved at the importing site.



In addition, to ensure that classification and license attributes are retained whenclassified data is imported to a remote site, you should first verify that the clearanceand classification values and AM rule tree entries are synchronized between the sites.

The following points should also be considered when working with classified data ina Multi-Site Collaboration environment:

• Licenses are defined independently at each site and must be matched whendata is imported.

• Licenses are not automatically exported with data objects; however, references tothe licenses are exported with the data object.

• The TC_multi_site_ada_license_user_bypass preference can be set to allowlicenses to be re-attached to replicated objects upon import, even when theimporting user does not have the privileges required to attach such a license.

• If a license with the same ID as that referenced by the data object exists at theimporting site, the association is maintained.

• If a data object references a license ID that does not exist at the importing site,there are no IP privileges on the object when it is imported.

• Classification values assigned to data are preserved when the data is imported.

• The ADA_override_on_import preference can be set to keep IP andgovernment classification values on a workspace object in sync between themaster and replica sites.

Basic tasks for configuring and administering ADA for IP data

About the tasks for configuring and administering authorized data access for IPdata

The following basic tasks must be performed when configuring and administeringauthorized data access for intellectual property (IP) data:



Enabling authorized data access

Authorized data access (ADA) features are not enabled by default when youinstall Teamcenter. To enable ADA, set the ADA_enabled preference to true.For information about setting preferences, see the Preferences and EnvironmentVariables Reference.

Configuring logging and blocking in NX

The TC_session_clearance preference, in conjunction with NX runtime properties,enables you to establish indirect access controls in NX using logging or menusuppression (blocking) to control classified data that is loaded in a TeamcenterIntegration for NX session.

Logging provides auditable evidence of the use of various NX commands on classifieddata. This is implemented by NX internal mechanisms that are beyond the scope ofthis document. For more information, see the NX Help Library.

Blocking suppresses NX menus that, if used on classified data, could result inexporting geometric data outside the NX/Teamcenter managed environment. Theblocking feature also provides menu action logging.

While allowing data out of the managed environment creates a security vulnerability,you may at times want to grant a user permission to use NX menus that involveexporting data out of the environment. You can use the Unmanage privilege inAccess Manager to grant users the ability to access these restricted features.

Configuring logging and blocking is optional.



Defining IP clearance and classification levels

Each site defines a list of intellectual property (IP) classification values and clearancelevels that are assigned to data objects and users for IP access evaluation. The list ismaintained in the IP_level_list_ordering preference. For example, you define alist of the Secret, Confidential, and Top Secret access levels. The order in whichthe levels appear in IP_level_list_ordering defines their restrictiveness. The firstentry is the lowest classification, and the last entry is the highest. Access Managercompares these values to determine user access rights to an object.

The IP classification values are propagated to related objects according to thepropagation rules defined in Teamcenter (when setting the value on an item,all revisions and their attached datasets gets the same value). This only applies,however, when setting a value that is more restrictive than the current value. If youset a less restrictive value on an object, the value is not propagated to the relatedobjects.

For example, if you set a classification value of Top Secret on the 001–Axel part,it is propagated to the related objects because its classification is more restrictivethan the IP classification of the related objects (Secret):

In the following example, however, if you set an IP classification value of Secret)on the 001–Axel part, it is not propagated from 001–Axel to the related objectsbecause it is less restrictive (at a lower level) than the IP classification level set onthe related objects (Top Secret):

You can replace an IP classification level with another of equal value. For example,in the following example, Confidental is replaced with Secret because it is atthe same level.

Note Classification values that are of equal value are separated by commas in theIP_level_list_ordering preference.



Assigning IP Admin role and grant IP Admin privileges

See listing of all ADA roles.

The IP Admin privilege is required to specify IP classification on data objects.The privilege to administer IP licenses is defined by the value specified for theADA_license_administration_privilege preference (ITAR_ADMIN by default).The same privilege is required to add and remove users from licenses and set licenseexpiration dates, typically by either being the owning user or being assigned tothe IP Admin role.

Applying licenses to or removing licenses from objects requires that the user have IPAdmin privileges on both the license and the object to which the license is beingapplied.

Users can be assigned to the IP Admin role by a Teamcenter administrator usingthe Organization application.

For more information about assigning users to roles, see the Organization Guide.

Note License creation is not controlled by Access Manager rules.

Assigning users to classify data

Use the Organization application to assign users to the IP Classifier role toallow them to classify IP information without granting all of the privileges of theIP_ADMIN. Users of these roles must be granted the IP_Classifier privilege.

For more information, see the Organization Guide.


Comparison of roles

The following table provides information at a high level about the actions that userswith ITAR_ADMIN, IP_ADMIN, ITAR_Classifier, and IP_Classifier privilegescan perform (there are minor exceptions for attaching or detaching licenses):

Action ITAR_ADMIN IP_ADMIN ITAR_ClassifierIP_Classifier

Create ITAR,IP, or excludelicense

Yes, ifpreferenceADA_license_administration_privilegeis set toITAR_ADMIN

Yes, ifpreferenceADA_license_administration_privilegeis set toIP_ADMIN

No No

Modify ITAR,IP, or excludelicense



No No




Delete ITAR,IP, or excludelicense



No No

Attach ITARlicense to aworkspaceobject

Yes No No No

Attach IP orexclude licenseof workspaceobject

No Yes No No

Detach ITARlicense fromworkspaceobject

Yes No No No

Detach IPor excludelicense fromworkspaceobject

No Yes No No

Set or modifygovernmentclassificationon workspaceobject

Yes No Yes No

Set ormodify IPclassificationon workspaceobject

No Yes No Yes

Set or modifyIP clearancefor a user

No Yes No No




Set or modifythe followingvalues for auser:

• Governmentclearance

• TTC Date

• Nationality

• Geography

Yes No No No

For more information, see the Authorized Data Access License Guide and theOrganization Guide.

Recommended rules for intellectual property (IP) classification ofworkspace objects

The following are examples of recommended rules and access control lists (ACLs) forusers performing IP classification of workspace objects.



Assigning clearance levels to users

Use the Organization application to assign IP clearance levels to users. Theclearance value assigned to the user must match a value defined in theIP_level_list_ordering preference. For information about modifying userattributes, see the Organization Guide.

Creating IP licenses

Users who have the same privilege as the value set for theADA_license_administration_privilege preference can create andmaintain intellectual property (IP) licenses in the ADA License application. Oncecreated, privileges are either granted or denied to users by associating the licensedirectly with the data object.

For more information, see the Authorized Data Access License Guide.

Assigning classification values to data objects

Access to classified data is determined by an evaluation of the user’s clearance leveland the classification level that is applied to the object. The IP Classificationproperty specifies the classification level of an individual object and can be viewedand modified in the same manner as other object properties. Valid values for thisproperty are derived from the IP_level_list_ordering preference. Users must haveIP Admin or IP Classifier privileges to classify objects in Teamcenter.

Note The Classification, Classified, and Classified in properties apply to theTeamcenter Classification application, which is used to categorize objectsfor reuse. They do not apply to classification for the purpose of authorizingdata access.



Assign an IP classification value to an object

Tip You can also display and modify object properties in the Details pane byselecting the object and choosing Details from the list in the upper-rightcorner of the Teamcenter window. This method allows you to assign aclassification value without performing the extra steps required to displaythe Properties dialog box.

1. In the tree display in My Teamcenter, right-click the object to be classified.

2. From the shortcut menu, choose Properties.

3. In the Properties dialog box, click Edit.Teamcenter checks the object out of the database and opens it for edit.

4. Click the All link in the blue bar at the bottom of the dialog box to display all ofthe object properties.

5. Scroll to the bottom of the dialog box, and click the All link.

6. Scroll to locate the IP Classification property.

7. Type the IP classification value in the box.

This value must match one of the values specified in the IP_level_list_orderingpreference.

8. Save and check in the object.



Associating licenses with data objects

IP licenses grant named users discretionary, limited-time access to classified data.Users (IP administrators) who are assigned to the IP Admin role maintain them.They have Write and IP Admin privileges to both the object and the license. IPadministrators also attach licenses to data objects.

Note • You must have IP Admin privileges on both the object and the license toattach or remove licenses.

• You may want to set the ADA_enable_subgroups preference to specifywhether or not subgroup members of the top-level groups can beauthorized access to workspace objects with attached licenses when thetop-level group is not authorized access.

Attach IP licenses to a data object

1. In the My Teamcenter tree pane, right-click the object to which you want toattach the license.

2. From the shortcut menu, choose License→Attach .

3. In the Assign an Object to Licenses dialog box, select the license that you wantto attach to the object.

4. Click OK.

Configuring ADA for ITAR support

About configuring ADA for ITAR support

Teamcenter allows you to control access to data that is deemed military in nature.For example, technical information may be subject to International Traffic in ArmsRegulations (ITAR) policies and, if so, must be protected so that only citizens of theUnited States have open access to the data. Viewing this classified data outside theU.S. is considered equivalent to performing an ADA (authorized data access) exportof it, which requires that rights are granted by license. Teamcenter can grant accessrights for a specific time period to citizens of other countries, U.S. citizens physicallylocated outside the United States, or organizations that are named in an effectiveTechnical Assistance Agreement (TAA). Information marked as nontechnical is, forthe purposes of ITAR, available to all users.

Note Do not confuse an ADA export with other Teamcenter export actions. Forexample, a Multi-Site Collaboration export from a site within the UnitedStates to another U.S. site is not an ADA export.

If you implement ITAR controls at your site, an ITAR administrator can use AccessManager to control each user’s rights to read or modify the status of technical dataor ADA export it, based on ITAR markings, TAA licenses, and the user’s citizenship.You can mark any object in the system (including parts, design files, and documents)as government classified, thus enabling ITAR access control on it. ITAR markingsare internationally recognized codes including the USML (United States Munitions



List) and the ECCN (Export Control Classification Number). The mechanism ofassigning codes to data is determined by your company’s business practices and isnot controlled by Teamcenter.

You can define the following attributes for each user:

• A nationality, citizenship (one or more) and geography (physical location).Teamcenter uses these attributes to determine if the user is a foreign (non-U.S.)national for ITAR purposes or a U.S. national located outside the U.S. In either ofthese cases, if the user views classified material, it is considered an ADA exportand requires a license granting rights to export.

• Government clearance status and technology transfer certification (TTC) dateto track the user’s level of clearance for viewing data marked as governmentclassified. Teamcenter revokes the user’s access rights after the TTC date expiresunless renewed. The administrator may manually cancel a TTC at any time.

In the same way, Teamcenter tracks the geography of each site in the system and canconsequently determine if a site that requests data is domestic or foreign. It usesthis information with the user attributes to determine if the requesting user is aforeign national or a domestic national.

The ITAR administrator creates each TAA as a separate license that is assigned to anamed group (a corporation or other organization). Teamcenter tracks all groupsthat are issued with TAAs and their expiry dates.

For details of how to maintain groups, geography, and licenses, see the OrganizationGuide.

You can also configure logging and menu suppression (blocking) to be applied whenclassified data is loaded in Teamcenter Integration for NX. Logging provides an auditof actions taken on exported data, and blocking suppresses NX menus to preventgeometric data from being exported outside of the NX/Teamcenter environment.

Applying Access Manager concepts to technical data subject to ITAR

Basic Access Manager concepts and terms related to ITAR

The following concepts are key to understanding how to apply Access Managerconcepts to data subject to ITAR.

Concept Description

Government classification Government classification is anobject attribute that can be used inconjunction with the user’s governmentclearance level to validate their accessprivileges. This requires that thegovernment clearance on the userand the government classificationon the object come from a commonmultilevel scheme defined by theITAR_level_list_ordering preference.

The government classification attributecan also be used to describe the object.Descriptive classification values are



Concept Descriptiontypically United States MunitionsList (USML) codes or Export ControlClassification Number (ECCN) codes.When used in this way, the value of theITAR_level_list_ordering preferenceis null.

Government clearance Government clearance is a user attributethat specifies the level of clearance thatusers have to classified data.

Note Valid classification andclearance values are derivedfrom the values set for theITAR_level_list_orderingpreference.

Nationality and citizenship Nationality and citizenship areattributes that specify the nationalityand citizenship of a user or organization(group) and enables access rulesto determine whether the user ororganization is domestic or whether anITAR license is required. Appropriatevalues for this field are two-characterISO 3166 codes.

These attributes are evaluated when theAccess Manager rule tree includes rulesthat use the User Nationality, GroupNationality, User Citizenship, orUser Citizenship Or Nationalitycondition.

Geography Geography is an attribute that specificsthe geographic location of the user orsite. International Traffic in ArmsRegulations specify that U.S. nationalslocated outside the United States mustbe named in an effective TechnicalAssistance Agreement (TAA) to accessclassified data. Appropriate values forthis field are two-character ISO 3166codes.

This attribute is evaluated when theAccess Manager rule tree includes rulesthat use the User Geography or SiteGeography condition.



Concept Description

Organization An organization in the authorized dataaccess context is a Teamcenter groupthat models a legal corporation orcompany whose members can be grantedaccess to classified data. An organizationhas the following attributes that arederived from ISO 6253 standards:Organization Name, Organization LegalName, Organization Alternate Name,Organization Address, OrganizationURL, Organization Status, OrganizationID, Organization Type, Nationality.

Note Organizations are Teamcentergroups and as such are subjectto hierarchical group behavior.Therefore, sub-groups inheritthe properties of the parentgroup. Siemens PLM Softwarerecommends that users be mademembers of the most specificgroup possible to ensure theaccuracy of key attributes,such as the nationality of theorganization.

Technical Assistance Agreement Authorizing document that allows theexport of classified data to U.S. nationalslocated outside the United States or toforeign nationals.

Note In the context of authorized dataaccess (ADA), allowing access toclassified data is considered tobe an export. The use of exportin this context is unrelatedto transferring data betweenTeamcenter sites.

Technology Transfer CertificationDate

Date upon which the user’s accessto view data marked as governmentclassified expires.

ITAR license Grants access for U.S. nationals outsidethe United States or foreign nationalsnamed by an effective TechnicalAssistance Agreement to accessprotected product data, which in theUnited States could contain technicalinformation that is restricted by ITAR.



Concept Description

ITAR Admin privilege ITAR Admin privileges must beexplicitly granted and denied to preventuser from gaining unauthorized accessto ITAR data.

ITAR Classifier privilege The ITAR Classifier privilege lets usersclassify data without having all theprivileges of the ITAR Admin. It must beexplicitly granted and denied to preventusers from gaining unauthorized accessto ITAR data.

Access Manager rules for protecting data subject to ITAR

Access Manager rules allow you to establish access controls on data that is subjectto ITAR. The following rule conditions and accessor types are used to configureITAR data access rules.

For a list of recommended rules and access control lists (ACLs) for managing ADAlicenses, see Authorized Data Access License Guide.

Condition Value DescriptionUserCitizenship

Two-character ISO3166 codes identifyinga country.

This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser without a U.S.citizenship.

Checks whether the user has specificcitizenship.

UserCitizenshipOrNationality


This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser not without a U.S.citizenship.

Checks whether the user has specificcitizenship or nationality.

UserNationality


This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser not from the U.S.

Specifies the nationality of a user.




GroupNationality

Two-character ISO3166 codes.

This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser belonging to agroup not from theU.S.

Specifies the nationality of a group ororganization.

UserGeography


This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser not located in theU.S.

Specifies the location of the user.

SiteGeography


This condition acceptsnegation using a minus(–) prefix. For example,“–us” indicates anyuser at a site notlocated in the U.S.

Specifies the location of the site.

User Is ITARLicensed

true or false If set to true, verifies the existence ofa valid ITAR license attached to theworkspace object being evaluated thatnames the current user or their group asa licensee.

HasGovernmentClassification

Specific governmentclassification attributevalues that canbe prefixed by thefollowing operators:

>>=<<==

Validates the government classificationattribute value of the object against thevalue specified for the condition.

The operators can be used without aclassification value; the governmentclassification attribute of the object iscompared to the user’s clearance levelbased on the specified operator.

Note If the object has no governmentclassification attribute value, thisrule does not apply.

Has NoGovernmentClassification

Matches if the object has a null value forthe government classification attribute.



Condition Value DescriptionUser HasGovernmentClearance

Specific governmentclearance values thatcan be prefixed by thefollowing operators:

>>=<<==

Validates the user’s governmentclearance level against the valuespecified for the condition.

The operators can be used without aclearance value; the user’s clearanceis compared to the governmentclassification attribute of the object basedon the specified operator.

User TTCExpired

Evaluates whether the TTC date for theuser who is logged on has expired.

User InLicense

Specifies whether the user who is loggedon is cited on the license object beingevaluated.

User InAttachedITAR License

Any or All Checks whether the user is on any or allITAR licenses attached to the workspaceobject being evaluated.

• If set to Any, the user is on at leastone ITAR license.

• If set to All, the user is on all ITARlicenses.

For more information, see Scenario –Using rules to control access to datathrough ADA licenses.

Has NamedITAR License

License ID Checks whether an object has an ITARlicense of the specified license ID. It doesnot check if a user is on the license.


User InNamed ITARLicense

License ID Checks whether a user is on an ITARlicense of the specified license ID. It doesnot check if the license is attached to theworkspace object being evaluated.


CitizenshipOn Any ADALic

citizenship Checks whether any or all of thecitizenships of the user currently loggedon matches any of the citizenships on theADA licenses attached to the workspaceobject being evaluated




CitizenshipOn Any ITARLic

citizenship Checks whether any or all of thecitizenships of the user currently loggedon matches any of the citizenships on theITAR licenses attached to the workspaceobject being evaluated.

CitizenshipOn Any IPLic

citizenship Checks whether any or all of thecitizenships of the user currently loggedon matches any of the citizenships on theIP licenses attached to the workspaceobject being evaluated.

CitizenshipOn AnyExclude Lic

citizenship Checks whether any or all of thecitizenships of the user currently loggedon matches any of the citizenships onthe exclude licenses attached to theworkspace object being evaluated.


User Excluded The user or their group is cited in a valid excludelicense attached to the workspace object beingevaluated. The exclude license is intended torevoke access on a limited time basis.

User ITAR Licensed The user is cited in any current ITAR licenseassociated with the selected workspace object.

User ITAR Unlicensed The user is not cited in any current ITAR licenseassociated with the selected workspace object.

User Under GovernmentClearance

The user’s government clearance is below thelevel required by the object. This accessor istypically used to revoke access and is onlyapplicable when the government clearance onthe user and the government classification on theobject come from a common multilevel schemedefined by the ITAR_level_list_orderingpreference.

User Has GovernmentClearance

Compares the user’s clearance with the objectclassification and tests whether the user hasclearance above, below, or equal to that requiredto access the object.

User Over GovernmentClearance

The user’s government clearance is over the levelrequired by the object. This accessor is typicallyused to grant access and is only applicable whenthe government clearance on the user and thegovernment classification on the object comefrom a common multilevel scheme defined by theITAR_level_list_ordering preference.



Scenario – Using rules to control access to data through ADA licenses

About using rules to control access to data through ADA licenses scenario

The following use cases illustrate how to use Access Manager rule conditionsto manage access to data using Authorized Data Access (ADA) licenses. Thesescenarios use International Traffic in Arms Regulations (ITAR) examples. Thereare also corresponding rule conditions for managing access to data using all types oflicenses so these concepts pertain to any license type.

• Use case — Checking for users on named licenses

• Use case — Checking for users on a given type of license

• Use case — Checking for attached license by name

•

Use case — Checking for users on named licenses

The following use case illustrates how it is not necessary to attach a license to everyobject that you want protected. Instead, you can use the ACL rule condition UserIn Named ITAR License and the object’s classification together to control access.User In Named ITAR License checks to see if a user is listed on a specified license.It does not check if the license is attached to the object.

Note There are also corresponding rule conditions for all types of licenses, sothese concepts pertain to all licenses:

• User In Named IP License

• User In Named Exclude License

• User In Named License

Use case 1 – Restricting access based on named licenses

ABC Company builds the following Access Manager rules, allowing the World tohave read access:

Has GovClassification = Secret

User In Named ITAR License (ITAR 001)

World –> Read

The ITAR 001 license has three users named on it (User1, User2, and User3).In addition, the item trying to be accessed, Item001, has a gov_classificationset to secret

Using the User In Named ITAR license rule condition, User1 can read Item001because User1 is listed on the license, while User4 cannot read Item001 becauseUser4 is not listed on the license.



Use case — Checking for users on a given type of license

The following use cases illustrate how to check that a user is allowed access to anobject if the user is named on any or all of the specified ADA licenses that areattached to the object. It uses the following rule conditions:

• User In Attached ITAR License

• User In Attached IP License

• User In Attached Exclude License

• User In Attached License

Because these are rule conditions, you can AND them together to build a check thatdetermines whether the user is on all ITAR and IP licenses before being given access.

You could use accessors on the ACL, but they can only be OR’ed together. Therefore,you cannot check that the user is on both an ITAR and IP license.



Use case 1 – User can be on any licenseABC Company builds the following Access Manager rule, which states that a useronly needs to be on one or more of the ITAR licenses attached to an object to be givenaccess to that object, with World having read access:

User In Attached ITAR License (Any)

World –> Read

User1 is listed on one of the licenses attached to Item001, as shown next. Therefore,User1 is allowed access to Item001. User5, on the other hand, is not listed on anyof the ITAR licenses attached to item002 so User5 is not given access to Item002.

User 2 – User must be on all licensesABC Company builds the following Access Manager rule, which states that a usermust be on all ITAR licenses attached to an object to be given access to that object,with World having read access.

User In Attached ITAR License (All)

World –> Read



In this use case, User1 is listed on all licenses attached to Item001, and, therefore,User1 is allowed access to Item001. User5 is denied access to Item002 because heis only listed on two of the three ITAR licenses attached to Item002.

Use case — Checking for attached license by name

The following use case illustrates how you can configure access to check if an objecthas a license of a specific name.

The following conditions would be used to set this type of checking:

• Has Named ITAR License

• Has Named IP License

• Has Named Exclude License

• Has Named License

Note These conditions do not check if the user is on the license.

Using these conditions, you can configure access to check if the object has a specificITAR license AND the user is also named on that license.

Similarly, you can check for these conditions for both ITAR and IP (AND’d together):



Use case 1 – Checking for attached license by nameABC Company builds the following Access Manager rule, which states that a useris allowed access to a workspace object if there is an ITAR license by the nameITAR001 attached to that object, with the World having read access:

Has Named ITAR License (ITAR001)

World –> Read

User1 is allowed access because there is an ITAR license ITAR001 attached toItem001, as shown next. However, User1 is not allowed access to Item002 becauseITAR001 license is not attached to it.

Use case — Checking user citizenships on attached licenses

The following use case illustrates how you can configure access to check if a user’scitizenships are on the license’s citizenship list.

The following conditions would be used to set this type of checking:

• Citizenship On Any ADA Lic

• Citizenship On Any ITAR Lic



• Citizenship On Any IP Lic

Because these are rule conditions, you can AND them together to build a checkthat determines whether the user citizenship is on all ITAR and IP licenses beforebeing given access.

Use case 1 — Any of a user’s citizenships are on the license citizenship listABC Company builds the following Access Manager rule, which states that onlyusers with US or Great Britain citizenships are allowed to access certain data, withWorld having read access:

Citizenship On Any ITAR Lic ITAR (Any)

World –> Read

User1 has citizenships GB and CA and User2 has a citizenship of FR. Two ITARlicenses are attached to Item001, with US listed in ITAR001, and US and GBlisted in ITAR002, as shown. Therefore, User1 is allowed access to Item001, butUser2, whose citizenship FR is not listed on any of the ITAR licenses attached toItem001, is not given access.

User case 2 – All citizenships of the user must be on a citizenships list oflicenseABC Company builds the following Access Manager rule, which states that all user’scitizenships must be on the citizenship list of ITAR licenses attached to an object tobe given access to that object, with World having read access.

Citizenship On Any ITAR Lic ITAR (Any)

World –> Read

In this use case, User3 citizenships (GB and US) are all listed on the citizenshiplist of the ITAR licenses attached to Item002. Therefore, User3 is allowed access toItem002. User4 is denied access to Item002 because one of his two citizenships (IR)



is not listed on any of the citizenship lists of the ITAR licenses attached to Item002even through his citizenship GB is listed.

Propagating ADA licenses

Authorized data access (ADA) licenses are propagated to related objects, basedon relation propagation rules when the licenses are attached to workspaceobjects. This behavior is dependent on the value (true by default) specified forthe ADA_allow_license_propagation preference. Also, ADA licenses can bepropagated to a new object when the object is created using the Save As command.License propagation is determined by relation propagation rules and the valuesspecified for the ADA_saveas_propagated_license_types preference.

For more information about ADA license propagation, see the Authorized DataAccess License Guide.

For information about the ADA_allow_license_propagation andADA_saveas_propagated_license_types preferences, see the Preferences andEnvironment Variables Reference.

Scenario for implementing ADA for government classified data

In this scenario, Access Manager rules, government classification, user nationality,geographic location, and ITAR licenses are used to control access privileges to data.

In this example, the ABC Part Company is implementing rules to control privilegesto classified and nonclassified data. To do this, they have created a single ITARlicense, license 1, which grants access to Jane Davis. They have also assignednationality, geographic locations, and ITAR admin privileges to users, as follows.

User Nationality Geography ITAR AdminJane Davis GB UK No

Robert Smith US US No

Peter Taylor US US Yes



Dataset ID Government classification License

ABC0001 None None

ABC0002 usml=XI(a)(3),eccn=2B991 None

ABC0003 usml=XI(a)(3),eccn=2B991 license 1

ABC Part Company has also created three access control lists (ACLs):ITARAdminACL, ITARACL, NoITARACL, and NoAccess.

The ACLs are defined, as follows:

• ITARAdminACL ACL

Role ITAR Admin

World

• ITARACL ACL

User ITAR Licensed

Role in Owning Group ITAR Admin

World

• NoITARACL ACL

Role in Owning Group ITAR Admin

World

• LimitedAccess ACL

Owning User

User ITAR Licensed

User Over GovernmentClearanceWorld

The ITARAdminACL, ITARACL, NoITARACL, and LimitedAccess ACLs areused in the following rules:



Has Class (POM_object)

Has Bypass (true) –> Bypass

Has Government Classification() –> ITARACL

User Nationality(“–us”) –> LimitedAccess

User Geography(“–us”) –> LimitedAccess

Has No Government Classification() –> NoITARACL

Has Class(User) –> ITARAdminACL

Has Class(POM_object) –> System objects

In addition to these rules, ABC Part Company can set the TC_session_clearancepreference to provide one of three levels of monitoring: unset, blocking, or logging.The Unmanage privilege can be granted to allow users to circumvent the blocking,if applicable. For more information, see Configuring logging and blocking in NX.

SessionClearance User Dataset Classification License Read

ITARLogged


block davisj ABC0001 none none Y N Y Y

block smithr ABC0001 none none Y N Y Y

block taylorp ABC0001 none none Y N Y Y

block davisj ABC0002 usml=XI(a)(3)eccn=2B991

none N N/A N/A N/A

block smithr ABC0002 usml=XI(a)(3)eccn=2B991

none Y Y N N

block taylorp ABC0002 usml=XI(a)(3)eccn=2B991

none Y Y Y Y

block davisj ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y N N

block smithr ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y N N

block taylorp ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y Y Y

log davisj ABC0001 none none Y N Y Y

log smithr ABC0001 none none Y N Y Y

log taylorp ABC0001 none none Y N Y Y

log davisj ABC0002 usml=XI(a)(3)eccn=2B991

none N N/A N/A N/A

log smithr ABC0002 usml=XI(a)(3)eccn=2B991

none Y Y Y N

log taylorp ABC0002 usml=XI(a)(3)eccn=2B991

none Y Y Y Y



SessionClearance User Dataset Classification License Read

ITARLogged


log davisj ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y Y N

log smithr ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y Y N

log taylorp ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y Y Y Y

unset davisj ABC0001 none none Y N Y Y

unset smithr ABC0001 none none Y N Y Y

unset taylorp ABC0001 none none Y N Y Y

unset davisj ABC0002 usml=XI(a)(3)eccn=2B991

none N N/A N/A N/A

unset smithr ABC0002 usml=XI(a)(3)eccn=2B991

none Y N Y N

unset taylorp ABC0002 usml=XI(a)(3)eccn=2B991

none Y N Y Y

unset davisj ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y N Y N

unset smithr ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y N Y N

unset taylorp ABC0003 usml=XI(a)(3)eccn=2B991

license 1 Y N Y Y

ITAR implementation considerations

Access Manager considerations for ITAR

Placement of rules in the Access Manager rule tree for ITARAccess Manager implicitly grants access privileges to data unless privileges areexplicitly revoked; therefore, rules to identify users with ITAR clearance or licenseshould be placed high in the rule tree. If ITAR-related conditions do not apply, therule tree is evaluated and data access privileges are determined by other factors,such as project membership or object ownership, as the rule tree is evaluated.

Authorized data access rule precedence for ITAR and IPWhen both ITAR and IP access rules are in force at a site, ITAR rules must takeprecedence over IP rules. Therefore, you must place ITAR rules higher in the ruletree than IP rules.

NX security for classified data for ITAR and IP

When operating in Teamcenter Integration for NX mode, Teamcenter providessecurity metadata to NX. This metadata is computed using the user and dataproperties and directs how NX behavior is modified when processing secure data.Security metadata is constant in NX, even if the information changes in Teamcenter.For example, if a user is granted access to data in NX based on a license, and thelicense expires while the data is open in NX, the expiration is not recognized by NX



until the user attempts to save the data back to Teamcenter, at which point theoperation fails because the user’s license has expired.

Authorized data access logging and blocking supports NX datasets as well asnon-NX datasets that can be translated into a part file, including JT, Solid Edge,and CATIA data.

The following NX operations are affected when logging and blocking areimplemented.


File→Save As X

File→Print X

File→Plot X

File→Send to Package File X

File→Export→Part X

File→Export→Parasolid X

File→Export→User DefinedFeature

X

File→Export→CGM X

File→Export→STL X

File→Export→Polygon File X

File→Export→Author HTML X

File→Export→TeamcenterVisualization

X

File→Export→VRML X

File→Export→PNG X

File→Export→JPEG X

File→Export→GIF X

File→Export→TIFF X

File→Export→BMP X

File→Export→XWD X

File→Export→IGES X



File→Export→DXF/DWG X

File→Export→2D exchange X

File→Export→Heal Geometry X



File→Export drawings toTeamcenter

X




File→InteroperateFile→Collaborate X

Edit→Copy Display X

View→Visualization→High QualityImage

X

View→Visualization→CreateAnimation

X

Tools→NX Manager→ExportAssembly

X

Tools→NX Manager→Save OutsideTeamcenter

X

Tools→Part Families Create X

Tools→Part Family Update X

Assemblies→Components→CreateNew

X

Assemblies→Components→AddExisting

X

Assemblies→Components→SubstituteComponent

X

Assemblies→Components→PartFamily Update

X

Assemblies→Components→CreateNew Parent

X

Assemblies→Cloning→CreateClone Assembly

X

Edit→Paste [Pasting of acomponent]

X

Dragging a drawing template ontoa part

X

For more information about configuring logging and blocking, see Configuringlogging and blocking in NX.

Multi-Site Collaboration considerations for ITAR

• Authorized data access (ADA) licenses are considered to be local administrativedata and are maintained by individual sites.

• Take care when sharing classified data with other Teamcenter sites. It ispossible that when importing a mixture of classified and unclassified data, theuser who is performing the import could view data to which they do not haveclearance. Teamcenter tests for privileges when importing data, but the systemdoes not read the classification attribute until the object has been reassembledand saved at the importing site.



• Licenses are not automatically exported with data objects; however, references tothe licenses are exported with the data object.

• The TC_multi_site_ada_license_user_bypass preference can be set to allowlicenses to be attached to replicated objects upon import and to allow licensesattached to replicated objects to be imported, even when the importing user doesnot have the privileges required to attach such a license.

• To ensure that classification and license attributes are retained when classifieddata is imported to a remote site, you should first verify that the clearance andclassification values and AM rule tree entries are synchronized between the sites.

• The Geography property on site definitions can be used as the basis foraccess rules to control Multi-Site Collaboration privileges for exporting andtransferring data.

• The ADA_override_on_import preference can be set to keep IP andgovernment classification values on a workspace object in sync between themaster and replica sites.

Basic tasks for configuring and administering authorized data accessfor ITAR restricted data

About the tasks for configuring and administering authorized data access forITAR restricted data

The following basic tasks must be performed when configuring and administeringauthorized data access for intellectual property data:



Enabling authorized data access

Authorized data access (ADA) features are not enabled by default when youinstall Teamcenter. To enable ADA, set the ADA_enabled preference to true.For information about setting preferences, see the Preferences and EnvironmentVariables Reference.

Configuring logging and blocking in NX

The TC_session_clearance preference, in conjunction with NX runtime properties,enables you to establish indirect access controls in NX using logging or menusuppression (blocking) to control classified data that is loaded in a TeamcenterIntegration for NX session.



Logging provides auditable evidence of the use of various NX commands on classifieddata. This is implemented by NX internal mechanisms that are beyond the scope ofthis document. For more information, see the NX Help Library.

Blocking suppresses NX menus that, if used on classified data, could result inexporting geometric data outside the NX/Teamcenter managed environment. Theblocking feature also provides menu action logging.

While allowing data out of the managed environment creates a security vulnerability,you may at times want to grant a user permission to use NX menus that involveexporting data out of the environment. You can use the Unmanage privilege inAccess Manager to grant users the ability to access these restricted features.

Configuring logging and blocking is optional.

Defining ITAR clearance and classification levels

Each site can define a list of International Traffic in Arms Regulations (ITAR)(government) classification values and clearance levels that are assigned to dataobjects and users for ITAR access evaluation. The list is maintained in theITAR_level_list_ordering preference. For example, you define a list of the Secret,Confidential, and Top Secret access levels. The order in which the levels appearin ITAR_level_list_ordering defines their restrictiveness. The first entry is thelowest classification, and the last entry is the highest. Access Manager comparesthese values to determine user access rights to an object.

Note The examples in this guide do not use the classification attribute-clearancelevel comparison to implement authorized data access. In the examples, theclassification attribute is used to provide descriptive details about the object.

The government classification values are propagated to related objects according tothe propagation rules defined in Teamcenter (when setting the value on an item,all revisions and their attached datasets are assigned the same value). This onlyapplies, however, when setting a value that is more restrictive than the currentvalue. If you set a less restrictive value on an object, the value is not propagated tothe related objects.

For example, if you set a classification value of Top Secret on the 001–Axel part, itis propagated to the related objects because its classification is more restrictive thanthe government classification of the related objects (Secret):

In the following example, however, if you set a government classification value ofSecret on the 001–Axel part, it is not propagated from 001–Axel to the relatedobjects because it is less restrictive (at a lower level) than the governmentclassification level set on the related objects (Top Secret):



You can replace a government classification level with another of equal value. Forexample, in the following example, Confidental is replaced with Secret becauseit is at the same level.

Note Classification values that are of equal value are separated by commas in theITAR_level_list_ordering preference.

Assigning users to the ITAR Admin role and grant ITAR Admin privileges


The specific privilege required to administer licenses is defined by the value specifiedfor the ADA_license_administration_privilege site preference (ITAR_ADMINby default). The ITAR Admin role and the ITAR Admin privilege authorize usersto classify data objects and administer ITAR licenses.

License modification and deletion requires the user have the privilege defined bythe ADA_license_administration_privilege preference, either explicitly or in thecontext of a group or project. Adding and removing users from licenses and settinglicense expiration dates requires the same privilege, typically by being either theowning user or being assigned to the ITAR Admin role.

Applying licenses to or removing licenses from objects requires that the user haveprivileges specified in the ADA_license_administration_privilege site preferenceon both the license and the workspace object to which the license is being applied.

Users can be assigned to the ITAR Admin role by a Teamcenter administrator usingthe Organization application.

For more information about assigning users to roles, see the Organization Guide.

Note License creation is not controlled by Access Manager rules.

Assigning users to classify data

Use the Organization application to assign users to the ITAR Classifier role toallow them to classify ITAR information without granting all of the privileges of theITAR_ADMIN. Users of these roles must be granted the ITAR_Classifier privilege.





Comparison of roles

The following table provides a high level comparison of the actions that users withITAR_ADMIN, IP_ADMIN, ITAR_Classifier, and IP_Classifier privileges canperform (there are minor exceptions for attaching or detaching licenses):


Create ITAR,IP, or excludelicense



No No

Modify ITAR,IP, or excludelicense



No No

Delete ITAR,IP, or excludelicense



No No

Attach ITARlicense to aworkspaceobject

Yes No No No

Attach IP orexclude licenseof workspaceobject

No Yes No No

Detach ITARlicense fromworkspaceobject

Yes No No No

Detach IPor excludelicense fromworkspaceobject

No Yes No No

Set or modifygovernmentclassificationon workspaceobject

Yes No Yes No




Set ormodify IPclassificationon workspaceobject

No Yes No Yes

Set or modifyIP clearancefor a user

No Yes No No

Set or modifythe followingvalues for auser:

• Governmentclearance

• TTC Date

• Nationality

• Geography

Yes No No No

Recommended rules for international traffic in arms (ITAR) classificationof workspace objects

The following are examples of recommended rules and access control lists (ACLs) forusers performing ITAR classification of workspace objects.



Assigning ADA ITAR attributes to users

Authorized data access uses the government clearance, geography, and nationality,citizenship, and technology transfer certification date attributes associated with auser to evaluate access rules to determine access privileges. These attributes are setin the Organization application.




Assigning geographic locations to sites

Assigning a geographic location to a site enables you to write access rules tocontrol Multi-Site Collaboration privileges for exporting and transferring data. Thegeography attribute is set in the Organization application.


Assigning nationality to groups

You can set the nationality attribute on Teamcenter groups, which enables you touse the group as the basis for selectively granting users access to restricted databased on ITAR licensing. Groups are created and maintained using the Organizationapplication.




Note Teamcenter groups are subject to hierarchical group behavior. Therefore,subgroups inherit the properties of the parent group. Siemens PLM Softwarerecommends that users be made members of the most specific group possibleto ensure the accuracy of key attributes, such as the nationality of theorganization.

Creating ITAR licenses (Optional)

ITAR licenses provide discretionary (time limited) grants or denials of access to auser or users who do not have access to classified data based on their clearancelevel. ITAR licenses are the authorizing documents in Teamcenter that represent aneffective Technical Assistance Agreement (TAA). The ITAR license can have one ormore citizenships associated with it to restrict access.

Users who have the privilege specified in theADA_license_administration_privilege preference create and maintain licensesin the ADA License application. Once created, privileges are either granted ordenied to users by associating the license directly with the data object.


Assigning government classification values to data objects

Access to classified data is determined by an evaluation of the user’s clearance leveland the classification level that is applied to the object. The Gov Classificationproperty specifies the classification level of an individual object and can be viewedand modified in the same manner as other object properties. Users must have ITARAdmin or ITAR Classifier privileges to classify objects in Teamcenter.

Note The Classification, Classified, and Classified in properties apply to theTeamcenter Classification application that is used to categorize objects forreuse. They do not apply to classification for the purpose of authorizingdata access.

For more information, see the Classification Administration Guide.

Assign a government classification value to an object

1. In the tree display in My Teamcenter, right-click the object you want to classifyand choose Properties.

Tip You can also display and modify object properties in the Details pane byselecting the object and choosing Details from the list in the upper-rightcorner of the Teamcenter window. This method allows you to assigna classification value without performing the extra steps required todisplay the Properties dialog box.

2. In the Properties dialog box, click Edit.The system checks the object out of the database and opens it for edit.

3. Click the All link in the blue bar at the bottom of the dialog box to display all ofthe object properties.

4. Scroll to the bottom of the dialog box, and click the More link.



5. Scroll to locate the Gov Classification property.

6. Type the Gov classification value in the box.

7. Click Save and Check In.

Associating licenses with data objects

ITAR licenses grant named users discretionary, limited-time access to classified dataand are created and maintained by users who assigned to the ITAR Admin role.

Note • You must have privileges specified in theADA_license_administration_privilege preferences on both theobject and the license to attach or remove licenses.

• You may want to set the ADA_enable_subgroups preference tospecifies whether or not subgroup members of the top-level groups canbe authorized access to workspace objects with attached licenses whenthe top-level group is not authorized access.

Attach ITAR licenses to a data object

1. In the My Teamcenter tree pane, right-click the object to which you want toattach the license.

2. Choose License→Attach from the shortcut menu.

3. In the Assign an Object to Licenses dialog box, select the license that you wantto attach to the object.

4. Click OK.

Customizing Access Manager rules

By default, authorized data access (ADA) rules are not included in the AccessManager rule tree. You can add rules to support your company’s business processes.For more information about customizing Access Manager rules, see:

• Scenario for implementing ADA for government classified data

• ITAR implementation considerations

• Access Manager Guide


Chapter

10 Controlling access toclassification objects

Controlling access to classification objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Component display suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Hierarchy component protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

ICO protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

Classification access privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

Applying access controls examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Applying access controls examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Example: controlling the display of the hierarchy tree for Classification

users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Example: controlling access to hierarchy definitions . . . . . . . . . . . . . . . . . 10-6Example: controlling access to ICOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7Creating access rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

Create a classification access rule . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8Create a named access control list (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . 10-9Modify access control list entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10Delete access rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10


Chapter

10 Controlling access toclassification objects

Controlling access to classification objectsThe Classification Administration access control feature allows you to control accessto Classification objects (ICOs) and hierarchy components (groups and classes). Thisfeature is an extension of the Access Manager (AM) application and employs the AMtree of rules and access permissions to define access to objects. Rules created forClassification groups and classes are inserted into branches of the AM rule tree.

The basic concepts of access control are the same for both the ClassificationAdministration and Access Manager applications.

For more information, see the Access Manager Guide.

Caution To maintain consistency, Classification rules should not be edited inthe Access Manager application. Additionally, the Classification AccessControl feature and the Access Manager application cannot be usedsimultaneously.

For more information about access rights and Multi-Site, see Understanding accessrights.

Component display suppressionYou can suppress the display of individual groups and classes in the hierarchy basedon group, role, or user-specific controls. This enables you to customize the display ofthe hierarchy tree, providing users with only the Classification data that is relevantto their tasks. Component display suppression affects the display of the hierarchytree in both the Classification and Classification Administration applications. Whenvisibility of a hierarchy component is suppressed, the display of the component’schildren is also suppressed.

Hierarchy component protectionCreation and modification of groups, classes, and subclasses is controlled, enablingdifferent individuals to be responsible for maintaining different parts of thehierarchy.


Chapter 10 Controlling access to classification objects

ICO protectionPrivileges applied to groups and classes determine which user, or groups of users,can view, add, or modify the Classification objects (ICOs) associated with the groupor class. The following figure illustrates how privileges are evaluated to determine ifa user has the privileges required to update an ICO.

1. Set in Classification Administration, privileges on class definition.2. Set in Classification Administration, privileges on ICOs.3. Set in Access Manager application or as Object ACL on the workspace object (for example,

in My Teamcenter).

ICO write access

The following figure illustrates how privileges are evaluated to determine if a userhas the privileges required to delete an ICO.


Controlling access to classification objects

denied

no

yes

granted / not set

granted / not set

granted

WRITE_ICOS privilege on the ICO's class?1

ICO classifies an item or an item revision?

WRITE_ICOS privilege on the classified item or

item revision?3

WRITE privilege on the classified item or

item revision?3

DELETE privilege revoked

DELETE privilege granted

not set

denied

DELETE privilege on the classified item or

item revision?3

granted / not set

DELETE privilege on ICO?2

WRITE privilege on ICO?2

denied

denied

granted / not set

granted / not set

1. Set in Classification Administration, privileges on class definition.2. Set in Classification Administration, privileges on ICOs.3. Set in Access Manager application or as Object ACL on the workspace object (for example,

in My Teamcenter).

ICO delete access



Restrictions• The IDs of classes and groups to which you apply privileges must not contain

spaces.

• To maintain consistency, Classification rules should not be edited in the AccessManager application. Additionally, the Classification access control feature andthe Access Manager application should not be used simultaneously.

• Because you achieve access control in Classification by adding named ACLs tothe Access Manager rule tree, only members of the system administrator groupcan modify access privileges.

Classification access privilegesThe following table describes the Access Manager privileges, how they apply toClassification objects, and whether the privileges are inherited by children of theselected object within the hierarchy.

Privilege

Used byClassificationaccesscontrol Purpose Inherited?

Read (R) Yes Controls visibility of a group or class in the hierarchy tree. Whenread access is denied, the object is not displayed in the tree.

This privilege overrides privileges set for the Classification objects(ICOs) of a class. If read privileges are denied at the class level,but granted for the ICOs of the class, the ICOs are inaccessible.

Yes

Note Revoking the readprivilege cannotbe overridden in asubclass; however,granting the Readprivilege can beoverridden in asubclass.

Write (W) Yes Controls whether a group or class can be modified, and whenapplied to a class, controls whether subclasses and views can beadded to the class.

Yes

Delete (D) Yes Controls whether a group or class can be deleted from thehierarchy. Restrictions on deleting groups and classes mayprevent you from deleting an object to which you have deleteprivileges. For example, you cannot delete a class that has beenreferenced, regardless of the privileges granted.

Yes

Change (C) Yes Controls the right to define access control privileges. Yes

Promote (p) No Not applicable. Not applicable.

Demote (d) No Not applicable. Not applicable.

Copy (c) No Not applicable. Not applicable.

Export (X) No Not applicable. Not applicable.

Import (I) No Not applicable. Not applicable.

Transfer-out(x)

No Not applicable. Not applicable.

Transfer-in(i)

Yes Controls whether ownership of an object can be transferred fromone site to another.

No



Privilege

Used byClassificationaccesscontrol Purpose Inherited?

ChangeOwnership

No This privilege is used differently than in Access Manager.Here, the privilege is used to grant or revoke the privilege toselect shared sites for sharing classification data in Multi-SiteCollaboration.

No

Publish Yes Controls whether the group or class and its children can beshared to other sites. Additionally, if this privilege is denied, theuser will not be able to modify the list of shared sites in the classor group definition.

No

Subscribe No Not applicable. Not applicable.

Write ICOs Yes Controls whether objects can be classified and stored within aclass. Also controls whether existing Classification objects (ICOs)can be modified. Attributes of the ICOs associated with partfamily members cannot be modified unless write access is grantedto the part family template.

Yes

Note ICOs that classify workspace objects are subject to further restrictions.

For more information, see ICO protection.

Applying access controls examples

Applying access controls examples

The following examples show how to apply access controls.

• Example: controlling the display of the hierarchy tree for Classification users

• Example: controlling access to hierarchy definitions

• Example: controlling access to ICOs

Example: controlling the display of the hierarchy tree forClassification users

ABC Corporation manufactures widgets and uses Classification to classify theirdesign data, using the following hierarchy structure.

ABC Corporation’s design hierarchy structure

In-process designs are considered to be strictly confidential and only the Designwork group is allowed to view them prior to release.



To suppress the display of this Classification hierarchy data for all users exceptthose in the Design work group, protections are applied to the In-Process DesignsClassification group, as shown next.

Access controls applied to in-process design classification group

By granting read privileges to users in the Design work group and denying readprivileges to the world, the data in the In-Process Design Classification group andall of its child classes are only visible to users who have a role in the Design workgroup. In addition, the protected objects are only returned as query results to usersin the Design work group.

Note Read privileges to child classes of a read-protected Classification groupcannot be granted unless the user is one to whom read privileges are alsogranted at the Classification group level.

For example, John Smith, a member of the Marketing work group, cannotbe granted read privileges to the Widget A class because it is a child classof the In-Process Design group. As a child, it inherits the privileges of theparent group, and according to the rule defined in the figure above, onlyusers with a role in the Design work group can be granted read privileges tothe Widget A class. If, however, John Smith maintained dual roles in boththe Marketing and Design work groups, he could be granted read privilegeson the Widget A class.

Example: controlling access to hierarchy definitionsABC Corporation also maintains a library of standard parts that are accessibleto users throughout the organization. These parts are classified according to ahierarchy that includes storage classes for different types of parts.

Standard parts classification hierarchy

Only users in the StdPartsAdmin work group are allowed to perform maintenancetasks on this portion of the hierarchy (beginning with the Standard Parts group



as the root). Therefore, privileges must be set restricting the capability to modifyhierarchy definitions (group, class, view) to all but the StdPartsAdmin work group,as shown next.

Access controls applied to standard parts classification group

By granting write privileges to users in the StdPartsAdmin work group anddenying write privileges to the world, the definitions of the Standard PartsClassification group and all of its child classes are only modifiable by users whohave a role in the StdPartsAdmin work group. However, users in other groups arestill able to view the definitions.

Note Write privileges can be granted on child classes of a write-protected group.

Example: controlling access to ICOsClassifying the standard parts used to produce various models of widgets is atask assigned to the StdPts work group at ABC Corporation. While other workgroups within the organization must be able to view the data associated with theClassification objects (ICOs), such as the physical attributes of the part or cost data,only the StdPts group is allowed to classify new parts or modify the attribute valuesof existing part classifications.

To restrict write access to standard part ICOs for all users except those in theStdPts work group, protections can be applied to the Standard Parts Classificationgroup, as shown below.

Access controls applied to standard parts ICOs



By granting write privileges on the ICOs that are created under the Standard Partsgroup to users in the StdPts work group and denying those privileges to the world,the ability to create and modify ICOs is restricted to the StdPts group. However, allother users are able to view the ICOs and their data.

Note Creating an access rule under Privileges on ICOs controls access tostand-alone (nonclassifying) ICOs only.

Creating access rulesAccess Manager uses various conditions, or rules, to control and protect your data.These rules are global, they affect your entire Teamcenter site. Rules that apply toClassification data specify a named access control list (ACL) that is applied to theobject.

The AM rule tree displays the rules in force at your site. Each rule is assigned somelevel of relative importance. The rules near the top of the tree take precedence overrules lower in the tree. The Classification Administration Access Control panedisplays only the portion of the tree that applies to Classification objects.

Create a classification access rule

1. Click the Hierarchy tab.

Teamcenter displays the Hierarchy pane.

2. Choose the group or class in the hierarchy tree that is affected by the rule.

Teamcenter displays the definition pane for the group or class.

3. Click the Edit button on the toolbar to activate the definition pane.

4. If defining rules for a class, click the Access Control tab to display the AccessControl pane. When working with groups, the Access Control pane is displayedon the definition pane when you select the group.

The Access Control pane displays the two AM rule tree roots related toClassification, along with the standard Teamcenter Named ACL dialog box.

5. Choose the AM Rule tree root node that represents one of the following types ofrule you want to define:

• Privileges on class/group definition

• Privileges on ICOs

Privileges on class/group definition applies rules to the group or class and itsdescendants. Privileges on ICOs applies controls to the ICOs that are createdwithin the group or class.

6. Choose a named ACL from the list or create a new ACL.

For more information about creating ACLs, see Create a named access controllist (ACL).

Teamcenter displays the access control entries (ACEs) that comprise the namedACL in the table.



7. (Optional) Modify the access control entries.

For more information about modifying access control entries, see Modify accesscontrol list entries.

8. Click the Add button located at the bottom of the Access Control pane.Teamcenter adds the ACL to the rule tree.

9. Order the rules in the tree, as required, by using the up-arrow and down-arrowbuttons next to the tree. These rules are evaluated in order from top to bottomwhen a user attempts to access an object. Thus, a rule directly beneath the roottakes precedence over one further down the tree.

For more information, see the Access Manager Guide.

10. Click Save on the toolbar to save the new rule.

Create a named access control list (ACL)Note You must be in edit mode to create named ACLs.

1. Type a name for the new ACL in the ACL Name box.

2. Click the Create button located next to the ACL Name box.

Teamcenter creates the ACL. However, there are no entries associated with it.

3. Click the Add New ACL button .

A blank line appears in the ACL table.

4. Double-click in a blank cell in the Type of Accessor column to display a list ofpredefined accessor types. For additional information about accessors, see theAccess Manager Guide.

5. Select the accessor type that you want to use for this entry.

6. Double-click in a blank cell in the ID of Accessor column to display theSelect Accessor dialog box. This dialog box contains a list of predefined rolescorresponding to the type of accessor you selected in step 4.

7. Double-click the role that you want to apply to the accessor. You can also selectthe role in the dialog box and clicking OK.

Teamcenter displays the role of the accessor you selected in the ID of Accessorcolumn.

8. Define privileges for the accessor by double-clicking in the Privilege column andchoosing one of the following options:

Grant privilege

Deny privilege



Blank entries are also valid. Using blank entries enables rules to accomplishfocused objectives by allowing objects and accessors to fall through rules thatdo not apply to them.

9. To add additional entries to the named ACL, repeat steps 1 through 7.

10. Click Save located to the upper right of the ACL table.

Modify access control list entriesNote You must be in edit mode to modify named ACLs.

1. Choose the named ACL you want to change from the Named ACL list.

Teamcenter displays the details of the ACL in the table.

2. Modify privileges by double-clicking the column corresponding to the privilegeand choosing one of the following options:

Grant privilege

Deny privilege

Blank entries are also valid. Using blank entries enables rules to accomplishfocused objectives by allowing objects and accessors to fall through rules thatdo not apply to them.

3. Repeat steps 1 and 2 until all desired privileges have been granted or deniedfor this ACL.

4. Click the Modify button located at the bottom of the Access Control pane.

5. Click Save located to the upper right of the ACL table.

Delete access rulesAccess control rules can be removed from the rule tree and deleted from the database.

Note You must be in edit mode to delete access rules.

1. Click the Hierarchy tab. Teamcenter displays the Hierarchy pane.

2. Choose the group or class in the hierarchy tree that is affected by the rule.

Teamcenter displays the definition pane for the group or class.

3. Click the Edit button on the toolbar to activate the definition pane.

4. If you are deleting rules relative to a class, click the Access Control tab todisplay the Access Control pane. When working with groups, the AccessControl pane is displayed on the definition pane when you select the group.

The Access Control pane displays the two AM rule tree roots related toClassification, along with the standard Teamcenter Named ACL dialog box.



5. Choose the rule in the tree that you want to delete.

6. Click the Delete button located at the bottom of the Access Control pane.The rule is removed from the tree.

7. Click Save on the toolbar to save the change and delete the rule from thedatabase.


Chapter

11 Controlling access based oncompound property values

About controlling access based on compound property values . . . . . . . . . . . . . 11-1

Has Property condition example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1


Chapter

11 Controlling access based oncompound property values

About controlling access based on compound property valuesA compound property is a property on a business object that can be displayed as aproperty of an object (the display object) although it is defined and resides on adifferent object (the source object). Use the Has Property condition to controlaccess privileges based on compound property values.

Access Manager derives the value of compound properties on a given target objectfrom the attribute values on one or more secondary objects (auxiliary objects).The Has Property condition loads those secondary objects to retrieve the givencompound property value. If while retrieving the compound value an error occursbecause there is no read access on any secondary object or for similar reasons, therule evaluation fails and the rule is not applied to the target object.

Has Property works with types and compound properties. Configuring rules basedon compound properties whose values come from custom objects can only be doneusing the Has Property condition.

Note • Do not use Has Attribute conditions against custom properties. HasAttribute only works with classes and their persistent attributes. Forexample:

Has Attribute (Item:item_id=000013)

In this example, Item is the class and item_id is the attribute on theitem class.

• When creating rules containing both the Has Attribute and HasProperty conditions always use valid class and type names, respectively.If you use invalid class or type names, the rule evaluation fails and thepredicted access control behavior is not achieved.

For information about creating compound properties, see the Business Modeler IDEGuide.

Has Property condition example1. Using the Business Modeler IDE, create a compound property. In this case,

the fnd0_test_comp_prop compound property was added to the item with astring property value.


Chapter 11 Controlling access based on compound property values

2. Using the Access Manager, create a rule as given below.

For the option Do the following

Condition Select Has Property.

Value Type Item:fnd0_test_comp_prop=test value

ACL NameSelect an existing named ACL or create and selecta new named ACL. For example CompoundACLas given below.

The CompoundACL ACL grants privileges to Owning group and World asfollows.

Owning group

World

The Owning group is explicitly granted read, write, delete, change, and demoteprivileges.

The World accessor is explicitly denied read privileges.


Appendix

A Rule conditions, accessor types,and privileges

What are access rules composed of? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Rule tree conditions by group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Accessors by category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

Accessor precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Access privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11


Appendix

A Rule conditions, accessor types,and privileges

What are access rules composed of?Access rules are composed of conditions, accessor types, and privileges. Teamcenterprovides a tree of default rules, as well as accessor types and privileges that can beused to configure rules that grant or deny object access for users, groups of users,or project teams.

Rule tree conditions by groupThe following table lists the rule tree conditions by category. Click a condition tolearn more about it.

Condition Description

AdministrativeHas Bypass Specifies whether the user has bypass

privileges set. Bypass privilegesupersedes other privileges.

General

Has Attribute Specifies an attribute and valueassociated with a particular class.

Has Class Specifies an object class. The object isevaluated to determine if it is of thespecified class.

Has Description Specifies a description for the object. Theobject is evaluated to determine whetherthe description matches this value.

Has Form Attribute Enables access control of items anditem revisions by setting conditions onattributes of the Masterform class.

Has Item ID Specifies an item ID against which theitem is evaluated.

Has Name Specifies a name against which theobject is evaluated.

PLM00101 I Security Administration Guide A-1

Appendix A Rule conditions, accessor types, and privileges


Has Object ACL Specifies that an ACL is associatedwith an object. This condition does notexpect an ACL attached to a rule. It isa placeholder that indicates the point atwhich process ACLs and object ACLs areapplied in the rule tree hierarchy.

Has Property Specifies the value of a compoundproperty against which an object isevaluated.

Has Type Specifies the object type against whichthe object is evaluated.

Has Status Specifies the status type against whichthe object is evaluated.

Inactive Sequence Used in conjunction with the InactiveSequence Objects ACL. This conditionspecifies that previous sequences arehistorical and cannot be worked onindependently. The latest sequence isalways the working sequence for therevision.

In Job Specifies whether the target object is ina workflow job (process). This conditiondoes not expect an ACL attached to arule. It is a placeholder that indicatesthe point at which workflow ACLs areapplied in the rule tree hierarchy.

Note No subbranches can be addedbelow the In Job branch in theAccess Manager rule tree.

Is Archived Specifies that the object’s archive statusis evaluated.

Is Local Specifies whether the object’s residencein the local database is evaluated.This condition is used when Multi-SiteCollaboration is implemented.

Ownership/Accessor based

Is GA Specifies whether the user’s status asa group administrator in the currentgroup is evaluated.

Is SA Specifies whether the user’s systemadministration group membership isevaluated.

Owning Group Evaluates whether the object is ownedby the group under which the user islogged on to Teamcenter.

A-2 Security Administration Guide PLM00101 I

Rule conditions, accessor types, and privileges


Owning Group Has Security Evaluates whether the owning group ofthe object has a security string. Thiscondition is true only if the securityvalue of the owning group is equal to thevalue of this condition.

Owning Site Evaluates whether the object is ownedby the specified site. This condition isused when Multi-Site Collaboration isimplemented.

Owning User Evaluates whether the object is ownedby the specified user.

Incremental Change

In IC Context Enables structure edits (occurrenceedits, occurrence notes, transform edits,and attachment edits) to be controlled bythe Structure Manager, ManufacturingProcess Planner, Multi-StructureManager, or Part Planner application.

Project

In Current Project Specifies the project ID against whichthe object is evaluated.

Note This rule is not delivered withthe default installation ofTeamcenter. It must be addedmanually.

In Project Specifies a project to which the objectmust be assigned.

Is Project Member Specifies whether the user’s membershipin the project is evaluated. Thiscondition is only true when the user is acurrent member of the project.

Program

In Current Program Specifies access based on whether theprogram to which the data is assignedis the current program under which theuser is logged on to Teamcenter.

In Inactive Program Controls access to data based on whetherthe status of the owning program isinactive.

In Invisible Program Controls access to data based on whetherthe status of the owning program isinvisible.




Is Owned By Program Controls access to data based onwhether data is owned by the programspecified as a value for the Is OwnedBy Program condition.

Is Program Member Specifies whether the user’s membershipin the program is evaluated. Thiscondition is only true when the user isa member of the owning program or ashared program.

General Authorized data access (ADA) licenses

Citizenship On Any ADA Lic Check whether a citizenship of the usercurrently logged on matches any of thecitizenships applied to the ADA licensesattached to the workspace object beingevaluated.

Has ADA License Of Category Checks if any type of ADA license withthe specified category is attached to theworkspace object being evaluated.

Has Named License Checks whether a specific ADA license isattached to the workspace object beingevaluated.

User In Attach ADA Lic of Ctgry Checks if the user currently logged onis attached to the ADA license with thespecified category on the workspaceobject being evaluated.

User in Attached License Checks whether the user currentlylogged on is listed on any or all of theADA licenses attached to the workspaceobject being evaluated.

User In License Verifies that the user currently loggedon is listed in the ADA license beingevaluated.

User In Named License Checks whether the user currentlylogged on is listed on an ADA license ofthe specified name. It does not checkif the license is attached to the objectbeing evaluated.

International Traffic in Arms Regulations (ITAR)

Citizenship On Any ITAR Lic Check whether a citizenship of the usercurrently logged on matches any of thecitizenships applied to the ITAR licensesattached to the workspace object beingevaluated.

Group Nationality Specifies the nationality of a group ororganization.




Has Government Classification Validates the government classificationattribute value of the object against thevalue specified for the condition.

Has ITAR License Of Category Checks if an ITAR license with thespecified category is attached to theworkspace object being evaluated.

Has Named ITAR License Checks whether a specific ITAR licenseis attached to the workspace object beingevaluated.

Has No Government Classification Matches if the object has a null value forthe government classification attribute.

Site Location Specifies the location of the site.

User Citizenship Checks whether the user currentlylogged on has specific citizenships.

User Citizenship Or Nationality Checks whether the user currentlylogged on has specific citizenships ornationality.

User Has Government Clearance Validates the user’s clearance levelagainst the value specified for thecondition.

User In Attach ITAR Lic of Ctgry Checks if the user currently logged onis attached to the ITAR license withthe specified category on the workspaceobject being evaluated.

User In Attached ITAR License Checks whether the user currentlylogged on is listed on any or all of theITAR licenses attached to the workspaceobject being evaluated.

User In Named ITAR License Checks whether a user currently loggedon is on an ITAR license of the specifiedname. It does not check if the license isattached to the object being evaluated.

User Is ITAR Licensed Verifies the existence of a valid ITARlicense that names the current user as alicensee.

User Location Specifies the location of the user.

User Nationality Specifies the nationality of a user.

Intellectual property (IP) license

Citizenship On Any IP Lic Check whether a citizenship of the usercurrently logged on matches any of thecitizenships applied to the IP licensesattached to the workspace object beingevaluated.




Has IP License Of Category Checks if an IP license with the specifiedcategory is attached to the workspaceobject being evaluated.

Has Named IP License Checks whether a specific IP license isattached to the workspace object beingevaluated.

Has No IP Classified Matches if the object has a null value forthe IP classification attribute.

Object Has IP Classification Validates the IP classification attributevalue of the object against the valuespecified for the condition.

User Has IP Clearance Validates the user’s clearance levelagainst the value specified for thecondition.

User In Attach IP Lic of Ctgry Checks if the user currently logged onis attached to the IP license with thespecified category on the workspaceobject being evaluated.

User In Attached IP License Checks whether the user currentlylogged on is listed on any or all of theIP licenses attached to the workspaceobject being evaluated.

User In Named IP License Checks whether a user is on an IPlicense of the specified name. It does notcheck if the license is attached to theobject.

User Is IP Licensed If set to true verifies the existence of avalid (not expired) IP license that namesthe current user or their group as alicensee.

Exclude licenses

Citizenship On Any Exclude Lic Checks whether a citizenship of theuser currently logged on matches any ofthe citizenships applied to the excludelicenses attached to the workspace objectbeing evaluated.

Has Exclude License Of Category Checks if an exclusion license with thespecified category is attached to theworkspace object being evaluated.

Has Named Exclude License Checks whether a specific exclusionlicense is attached to the workspaceobject being evaluated.

User In Attach Excl Lic of Ctgry Checks if the user currently logged onis attached to the exclusion license withthe specified category on the workspaceobject being evaluated.




User In Attached Exclude License Checks whether the user currentlylogged on is listed on any or all ofthe exclusion licenses attached to theworkspace object being evaluated.

User In Named Exclude License Checks whether a user currently loggedon is listed in an exclusion license of thespecified name. It does not check if thelicense is attached to the object beingevaluated.

User Is Excluded Specifies whether the user or group iscited by a valid exclude license.

Accessors by categoryThe following table lists the accessors by category.


General

Owning User Users who initially created an object. Ownership can be transferred andadditional privileges (for example, delete) are usually granted to an object’sowner that are not granted to other users.

Owning Group Group that owns the object. Usually, it is the group of the user creating theobject. Additional privileges (for example, write) may be granted to the owninggroup, because it is common for users to share data with other members oftheir group.

Note By default, members of a subgroup receive the same access privilegesset on workspace objects as their parent group who owns the object(the owning group). To change the privilege inheritance, use theTC_allow_group_hierarchy_traversal preference.

Group Project-oriented cluster of users. This allows all users in a group to access acommon pool of project data regardless of the actual work each user performs.

Groups with Security Users who have the given security value, either Internal or External.

Role Function-oriented cluster of users.

Role in Group Users who have a specific role in a specific group. Use this for granting privilegesto all users performing the same skills and/or responsibilities on the sameproject.

Role in Owning Group Users with a specific role in the object’s owning group. This is useful for grantingprivileges to an inner circle of users with the same skills and/or responsibilitieson the same project. For example, all designers in the owning group are usuallygranted write privilege on their development data.

System Administrator Users who are members of the system administration group.

Group Administrator User who has special maintenance privileges for the group.

Site A specific site.

Remote Site Any site that is not local.

World Any user, regardless of group or role.

User A specific user.




User In License User is listed in the ADA_License object being evaluated.

For more information, see Controlling access to view and apply ADA licenses.

User Not In License User is not listed in the ADA_License object being evaluated.

For more information, see Controlling access to view and apply ADA licenses.

Workflow

Approver (RIG) Users who are members of a signoff team in a workflow process with a specificrole in a specific group (RIG).

Note This accessor is only used in workflow ACL and matches the signoffRIG requirements for the release level associated with the workflowACL.

Approver (Role) Users who are members of a signoff team in a workflow process in a specific role.


Approver (Group) Users who are members of a signoff team in a workflow process in a specificgroup.


Approver Users who are members of a signoff team in a workflow process regardless oftheir role and group.


Task Owner Task owner is given privileges for the task’s target data.

Task Owning Group The owning group are given privileges for the task’s target data.

Responsible Party Users responsible for performing a particular task. This ensures that only theuser assigned as responsible party is given privileges to the task’s target data.

Project

Project Team Team members in a particular project.

Project Teams Team members in any active project for the object.

Current Project Team Users who are members of a particular current project team. Applicable onlywhen the project is set as the current project of the team members and if thecurrent project is active.

Current Project Teams Users who are members of current project teams. Applicable only when the objectis in the current project of the team members, and the current project is active.

Role in Projects of Object Users who have a specific role in one of the projects of the object. This accessoris affected by the values set in the AM_PROJECT_MODE preference. It iseffective only when the user is logged-on with the specified role in the currentproject, and the current project is one of the projects assigned to the definedobject.

Role in Project Project members with a specific role in a specific project. This is affected by thevalues set in the AM_PROJECT_MODE preference.

Scheduler

Public Schedule Access to all users for schedules that are templates or made public. This accessorapplies to the Schedule Manager application.

RoleInSchedule Membership privileges of the logged-on user within a particular schedule.Member privileges (accessor IDs) can be COORDINATOR, PARTICIPANT, orOBSERVER. This accessor applies to the Schedule Manager application.




RoleInAnySchedule Membership privileges of the logged-on user across all schedules in the system.Member privileges (accessor IDs) can be COORDINATOR, PARTICIPANT, orOBSERVER. This accessor applies to the Schedule Manager application.

ADA

User In License User is listed in the ADA license object being evaluated.


User Not In License User is not listed in the ADA license object being evaluated.


User Excluded The user or group is listed in a valid exclude license attached to the workspaceobject being evaluated.

ITAR

User Has Government Clearance Compares the user’s clearance with the object classification and tests whetherthe user has clearance above, below, or equal to that required to access the object.

User ITAR Licensed The user is cited in a current license associated with the selected object.

User ITAR Unlicensed The user is not cited in a current license associated with the selected object.

User Under Government Clearance The user’s clearance is below the level required by the object. This accessor istypically used to revoke access and is only applicable when the governmentclearance on the user and the government classification on the object comefrom a common multi-level scheme defined by the ITAR_level_list_orderingpreference.

User Over Government Clearance The user’s clearance is over the level required by the object. This accessor istypically used to grant access and is only applicable when the governmentclearance on the user and the government classification on the object comefrom a common multilevel scheme defined by the ITAR_level_list_orderingpreference.

IP

User IP Licensed The user is cited in a current license associated with the selected object eitherdirectly or by membership in a cited organization (group).

User IP Unlicensed The user is not cited in a current license associated with the selected object.

User Has IP Clearance Compares the user’s clearance with the object classification and tests whetherthe user has clearance above, below, or equal to that required to access the object.

User Over IP Clearance The user’s clearance is over the level required by the object. This accessor istypically used to grant access and is only applicable when the IP clearance onthe user and the IP classification on the object come from a common multi-levelscheme defined by the IP_level_list_ordering preference.

User Under IP Clearance The user’s clearance is below the level required by the object. This accessor istypically used to revoke access and is only applicable when the IP clearance onthe user and the IP classification on the object come from a common multi-levelscheme defined by the IP_level_list_ordering preference.

Accessor precedenceAn accessor is a user or group of users who share certain traits, such as membershipin the group that owns the object or membership in the project team. The followinglist presents the predefined accessors delivered with Teamcenter in order ofprecedence, from most restrictive to least restrictive. The more restrictive theaccessor, the higher precedence it has over other accessors.



Note • When two accessors with different precedences are added to a namedACL configuration, the highest precedence accessor is automaticallymoved to the top in the ACL table.

• When two accessors with the same precedence are added to a namedACL configuration, they stay in the order they are added.

• The Role in Group, Role in Owning Group, Role in Project, andRole in Project of Object accessors work on the superset of rolesthe user possesses in the relevant group or project, rather than on thesession current role.

• When the TC_current_role preference is set, it affects the evaluation ofthe Role in Owning Group, Role in Group, and Role accessors.

• When the AM_PROJECT_MODE preference is set, it affects theevaluation of the Role in Project and Role in Project of Objectaccessors.



Access privilegesSymbol Privilege Description

Read Controls the privilege to open and viewan object.

Write Controls the privilege to check the objectin/out of the database and modify it.

Delete Controls the privilege to delete the object.



Symbol Privilege Description

Change Controls the privilege to modify objectprotections that override the rules-basedprotection for the object. You must havechange privileges to apply object-basedprotection (object ACLs).

Promote Controls the privilege to move a taskforward in a workflow process.

Demote Controls the privilege to move a taskbackward in a workflow process.

Copy Controls the privilege to copy an objectas a new object.

Note It still allows copy and paste ofthe object as a reference, with nonew object created.

Change ownership Controls the privilege required to grant,change, or restrict ownership rights to anobject.

Publish Controls the publish privilege to users orgroups.

Subscribe Controls the privilege to subscribe to anevent on a specified workspace object.

Export Controls the privilege to export objectsfrom the database.

Import Controls the privilege to import objectsin to the database.

Transfer out Controls the privilege to transferownership of objects when they areexported from the database.

Transfer in Controls the privilege to assign ownershipof objects when they are imported in tothe database.

Write ClassificationICO

Controls the privilege to writeClassification objects (ICOs).

Assign to project Controls the privilege to assign an objectto a project. This applies to users who arenot designated as privileged project teammembers.

Note The validation of the Assignto project privilege inconjunction with privilegedproject membership is evaluatedbased on the value of theTC_project_validate_conditionspreference.




Remove fromproject

Controls the privilege to remove an objectfrom a project. This applies to users whoare not designated as privileged projectteam members.

Note The validation of the Assignto project privilege inconjunction with privilegedproject membership is evaluatedbased on the value of theTC_project_validate_conditionspreference.

Remote checkout Controls the privilege to remotely checkout an object.

Unmanage Enables users to circumvent theblocking implemented using theTC_session_clearance preference.

IP Admin Enables users to add users to manage IPlicenses.

For more information, see the AuthorizedData Access License Guide.

ITAR Admin Enables users to add infodba users tomanage ITAR licenses.

For more information, see AuthorizedData Access License Guide.

CICO Grants a user the ability to override thecheckout of an object by another user. Itlets the user with the override privilegecheck in, transfer, or cancel the checkoutof the object.

Note CICO impacts an user’s abilityto check out objects when they donot have Write access. However, itdoes not impact their abilityto modify the object once it ischecked out.

Example If Bob checks out an object(item2) and forgets to checkit back in before leaving onvacation, the CICO privilegecan be granted to the projectmanager, Uma, so she can



Symbol Privilege Descriptioncheck item2 back in and theproject can proceed.

Translation Controls the privilege to add translatedtext using the Localization button.

For more information, see theLocalizationGuide.

View/Markup Controls the privilege to view and createmarkups.

For more information, see Getting Startedwith Document Management.

Batch Print Controls the privilege to print multipleobjects.

For more information, see Getting Startedwith Document Management.

Digital Sign Controls the privilege to digitally sign adocument. The Commercial Off-The-Shelf(COTS) Digital Sign Dataset ACL rulegrants owning user and owning groupdigital sign privileges for the datasetobject. World users do not have digitalsign privileges.

Administer ADALicenses

Controls the privilege to create, modify, ordelete ADA licenses for users in the ADALicense application.

For more information, see the AuthorizedData Access License Guide and theSecurity Administration Guide.

For more information, see the AuthorizedData Access License Guide and theAssigning users to classify data.

IP Classifier Controls the privilege to classifyintellectual property (IP) information.





ITAR Classifier Controls the privilege to classifyinternational traffic in arms (ITAR)information.


Remove Content Allows a user of 4th GenerationDesign (4GD) to remove content from acollaborative design (CD), for example, toremove an existing design element.

For more information, see 4th GenerationDesign Guide

Add Content Allows a user of 4GD to add content to aCD, for example, to create a new designelement.

For more information, see 4th GenerationDesign Guide


Appendix

B Glossary


Appendix

B Glossary

A

access control entry (ACE)In Access Manager, each pairing in the access control list of an accessor with thegranted privileges.

access control list (ACL)Access Manager component that contains a list of accessors and, for each accessor,the privileges granted, denied, and not set.

Access Manager (AM)Teamcenter application that enables the system administrator to grant users accessto Teamcenter objects.

accessorAccess Manager component that grants or denies privileges to clusters of users whoshare certain common traits (for example, perform the same function or work onthe same project).

ACESee access control entry (ACE).

ACLSee access control list (ACL).

action handlerHandler used to extend and customize workflow task actions. Action handlersperform such actions as displaying information, retrieving the results of previoustasks (inherit), notifying users, setting object protections, and launching applications.See also task handler.

action ruleBusiness rule that defines the actions required in different time phases (precondition,preaction, and postaction) for create, save as, and delete operations. Action rules areapplied to items, item revisions, and datasets.

ADA LicenseTeamcenter application that administers International Traffic in Arms Regulations(ITAR), intellectual property (IP), and exclude licenses. It provides enhanced controland new attributes for these licenses. ADA stands for Authorized Data Access.

AMSee Access Manager (AM).

PLM00101 I Security Administration Guide B-1

Appendix B Glossary

approverUser who has a signoff in a workflow process regardless of role and groupmembership. In Access Manager, the approver accessor is used to allocate privilegesthat apply to all signoffs (for example, read access). See also RIG approver, roleapprover, and group approver.

attributeNamed storage variable that describes an object and is stored with the object. Userscan search the database for objects using object attributes.

In an object, an attribute is a name/value pair; in the database, an attribute is a field.

B

BOMBill of materials.

• 100% BOM

The as sold product configuration, for example, the configuration of a car to bebuilt and shipped to the dealer.

• 120% BOM

Partial overlay of selected variant conditions. You cannot build the productfrom a 120% BOM.

• 150% BOM

Overlays of all possible variant configurations. You cannot build the productfrom a 150% BOM.

See also design bill of materials and manufacturing bill of materials.

BOM viewTeamcenter object used to manage product structure information for an item.

BOM view revision (BVR)Workspace object that stores the single-level assembly structure of an item revision.Access can be controlled on the structure (BOM view revision) independently ofother data. BOM view revisions are meaningful only in the context of the itemrevisions for which they are created.

BVRSee BOM view revision (BVR).

C

classSet of objects that share the same list of attributes but distinguishable by the valuethe attributes acquire for specific objects. For example, the Automobile class can bedefined by the brand, color, and price, but each car associated to the Automobileclass has a different brand, color, and price combination.

class hierarchyStructure defining subclasses that inherit the attributes of their superclasses, alsocalled their parents or ancestors.

B-2 Security Administration Guide PLM00101 I

Glossary

D

data modelAbstract model that describes how data is represented and used.

datasetTeamcenter workspace object used to manage data files created by other softwareapplications. Each dataset can manage multiple operating system files, and eachdataset references a dataset tool object and a dataset business object.

design bill of materialsList of components and subassemblies used to define an assembly structure, andthe representation of the assembly structure. Compare with manufacturing billof materials.

E

effectivityIdentification of the valid use of an aspect of product data tracked by unit, date, orintent. You can specify a start definition, end definition, or both for a particulareffectivity. There are three types of effectivities:

• Unit effectivity specifies the range of item units or serial numbers.

• Date effectivity specifies the range of dates. This is also known as anincorporation point.

• Intent effectivity specifies a purpose, target, or milestone, for example,Production, Prototype, or Carryover.

Exclude_LicenseDenies specific users or groups access to the attached workspace objects for a periodof time.

F

folderGraphical representation of an aggregation of objects, such as a group, class, orsubclass. For easy distinction in the class hierarchy, each of these aggregations hasa different type of folder icon associated with it: a group folder icon, a class foldericon, or a subclass folder icon.

formTeamcenter workspace object used to display product information (properties) in apredefined template. Forms are often used to create an electronic facsimile of ahardcopy form in Teamcenter. See also master form.

form typeSpecial type of the general POM Form class, which can have its own set of properties(attributes) associated.


Appendix B Glossary

G

group (Organization)Organizational grouping of users at a site. Users can belong to multiple groupsand must be assigned to a default group.

group administratorUser with special maintenance privileges for a group.

group approverUser who is a signoff in a workflow process with a specific group of users. In AccessManager, the group approver accessor is used in Workflow ACLs and matches thesignoff definition (that is, group) for the release level associated with the WorkflowACL. The group approver accessor ensures that only signoffs are given privileges, nota user who matches the group. See also approver, RIG approver, and role approver.

H

hierarchyStructure in which each node can have only one parent but possibly multiple siblingsand children.

I

Integration Toolkit (ITK)Set of software tools provided by Siemens PLM Software used to customizeTeamcenter or to integrate third-party or user-developed applications withTeamcenter. The ITK is a set of C functions used directly by Teamcenter and NX.

IP_LicenseGrants discretionary access to specific users or groups to workspace objects that haveIP classification. It grants the access for a specified period of time.

ITAR licenseGrants discretionary access to specific users or groups to workspace objects withITAR classifications for a specified period of time. It is typically used to grant accessfor a specific time period to citizens of other countries, United States (U.S.) citizensphysically located outside the U.S., or organizations that are named in an effectiveTechnical Assistance Agreement (TAA) through an International Traffic in ArmsRegulations (ITAR) license.

itemWorkspace object generally used to represent a product, part, or component. Itemscan contain other workspace objects including other items and object folders.

item revisionWorkspace object generally used to manage revisions to items.

M

manufacturing bill of materialsDefines how the product is manufactured, rather than how it is designed. Comparewith design bill of materials.


Glossary

master formTeamcenter workspace object used to display product information (properties) ina predefined template. Master forms are used to display product information ina standardized format.

master objectControlling object in a Multi-Site Collaboration network.

When an object is created and saved, that instance is the master object until itis exported with transfer of ownership. There can be only one master object in aMulti-Site Collaboration network, and only the master object can be modified. Ifa master object is replicated, it cannot be deleted until all replicated objects aredeleted.

My TeamcenterTeamcenter rich client application that is the main access point for managingproduct information. My Teamcenter provides the functionality for creating objectsin theTeamcenter database, querying the database for objects, checking in andchecking out objects, and managing tasks. Users can also open objects, automaticallylaunching the related application.

Each user has a personal My Teamcenter window that displays product informationas graphical objects. Although users share product information across the enterprise,they organize this information individually in personal workspaces.

N

named ACLNamed group of access controls. See also access control list (ACL).

naming ruleBusiness rule that defines the naming conventions for the string property value indifferent type objects. Naming rules can be attached to the following properties:

• Item ID, item revision ID, and name in item types• Dataset name, ID, and revision number in dataset types• Name form types

NXSiemens PLM Software’s next-generation digital product development system thathelps companies transform the product life cycle. It provides the complete life cycleof development processes in product design, manufacturing, and simulation.

NX IntegrationIntegration between Teamcenter and NX. NX Integration users have full accessto the Teamcenter user interface from NX, and they can also access NX from theTeamcenter user interface.

Teamcenter Integration for NX and NX Integration have the identical userinterface in NX. The difference between the two products is the level of Teamcenterfunctionality available. Teamcenter Integration for NX excludes certain Teamcenterfunctionality, such as workflow and product structure editing.


Appendix B Glossary

O

object-based protectionUse of access control lists to create exceptions to rules-based protection on anobject-by-object basis. Object access control lists are most useful for either grantingwider access or limiting access to a specific object.

OrganizationTeamcenter application that enables a system administrator to create and managecritical Teamcenter files and database entries. It is the point of access for creating acompany’s virtual organization and for performing system administration activitiessuch as volume creation, maintenance, and site administration. Organizationenables creation and management of person, user, role, and group definitions;definition of the hierarchical structure of the Teamcenter organization; managementof data volumes; and establishment and maintenance of Teamcenter sites.

ownerUser that owns an object, initially the user who created it. Ownership can betransferred from the owner to another user. An object owner usually has privilegesthat are not granted to other users (for example, the privilege to delete the object).

owning groupGroup that owns an object, usually the group of the user creating the object. Becauseusers commonly share data with other members of a group, additional privileges maybe granted to the owning group (for example, the privilege to write to the object).

owning siteMulti-Site Collaboration site where the master object resides. The owning site is theonly site where the object can be modified.

P

persistent object manager (POM)Interface between Teamcenter objects and the Relational Database ManagementSystem (RDBMS). The persistent object manager provides definition of classesby inheritance from other classes and definition of attributes, manipulation ofin-memory objects and support for their saving and retrieval to and from theunderlying RDBMS, support for applications accessing the same data concurrently,protection against the deletion of data used by more than one application, andsupport for the access control lists attributed to objects.

personDefinition containing real-world information about each Teamcenter user, such asname, address, and telephone number. Person definitions are stored as simple textstrings so that they can be easily changed and updated. The name must be unique.

POMSee persistent object manager (POM).

preferenceConfiguration variable stored in a Teamcenter database and read when a Teamcentersession is initiated. Preferences allow administrators and users to configure manyaspects of a session, such as user logon names and the columns displayed by defaultin a properties table.


Glossary

privileged team memberProject team member with privileges to assign and remove objects from thatproject. Compare with project team member.

processAutomation of a business procedure, describing the individual tasks and tasksequences required to complete a business procedure.

programBasis for identifying a group of objects available to multiple organizations, suchas program teams, development teams, suppliers, and customers for a particularpiece of work.

Program applicationTeamcenter application used to define programs and assign program team members,program team administrators, and privileged team members.

program team administratorProgram team member with privileges to modify program information and programteam members for that program. Only one program team administrator is allowedper program.

program team memberTeam member (user) who does not have privileges to assign objects to or removeobjects from their programs. Compare with privileged team member.

projectBasis for identifying a group of objects available to multiple organizations, such asproject teams, development teams, suppliers, and customers for a particular pieceof work.

ProjectTeamcenter application used to define projects and assign project team members,project team administrators, and privileged team members.

Project administratorTeamcenter super user with unrestricted access to administer projects they createusing the Project application. A Project administrator creates, modifies, and deletesproject information and team members.

project team administratorProject team member with privileges to modify project information and project teammembers for that project. Only one project team administrator is allowed per project.

project team memberTeam member who does not have privileges to assign objects to or remove objectsfrom their projects. Compare with privileged team member.

propagationProcess of transferring characteristics of one object to another object.


Appendix B Glossary

R

replicated objectCopy of master object residing at sites within a Multi-Site Collaboration network.See also master object.

RIG approverUser who is a signoff in a workflow process with a specified role and group. InAccess Manager, the RIG approver accessor is used in Workflow ACLs and matchesthe signoff definition (that is, role in group) for the release level associated withthe Workflow ACL. This accessor ensures that only signoffs are given privileges,not a user who matches the role in group. See also approver, group approver, androle approver.

roleFunction-oriented cluster of users that models skills and/or responsibilities. Thesame roles are typically found in many groups. In Access Manager, role is an accessorused to grant privileges to all users with the same skills and/or responsibilitiesregardless of project.

role approverUser who is a signoff in a workflow process with a specific role. In Access Manager,the role approver accessor is used in Workflow ACLs and matches the sign-offdefinition (that is, role in group) for the release level associated with the WorkflowACL. This accessor ensures that only signoffs are given privileges, not a user whomatches the role. See also approver, group approver, and RIG approver.

role in groupSpecific role in a specific group. In Access Manager, role in group is an accessorused to grant privileges to all users with the same skills and/or responsibilitiesin the same group.

role in owning groupSpecific role in the object’s owning group. In Access Manager, role in owninggroup is an accessor used to grant privileges to users with the same skills and/orresponsibilities on the same project. For example, all designers in the owning groupare usually granted write privilege on their development data.

rule handlerHandler used to integrate workflow business rules into Enterprise Process Modelingprocesses at the task level. Rule handlers attach conditions to an action. See alsotask handler.

rules-based protectionConditions or rules that control who can or cannot access objects. These rules areglobal (that is, they affect the entire Teamcenter site) and are enforced by the AccessManager. These rules are defined by a system administrator.

rule treeAccess Manager component the system administrator uses to grant users access toTeamcenter objects. It is a tree of rules and access permissions that when processeddetermines the access that each user has to a specified object.


Glossary

S

siteIndividual installation of Teamcenter comprising a single Teamcenter database,all users accessing that database, and additional resources such as hardware,networking capabilities, and third-party software applications (tools) required toimplement Teamcenter at that site.

T

task (workflow)Fundamental building block used to construct a process. Each task defines a set ofactions, rules, and resources used to accomplish that task.

task handlerSmall Integration Toolkit program or function. Handlers are the lowest levelbuilding blocks in Enterprise Process Modeling. They are used to extend andcustomize tasks. There are two kinds of handlers: action handlers and rule handlers.See also action handler and rule handler.

U

userDefinition that is the mechanism by which Teamcenter identifies and interacts witheach user. User definitions contain a name (derived from the person definition), userID, operating system name, and password.

W

workflowAutomation of the concept that all work flows through one or more businessprocesses to accomplish an objective. Using workflow, documents, information, andtasks are passed between participants during the completion of a particular process.

Workflow DesignerTeamcenter application that enables administrators to graphically design workflowprocess templates, incorporating company business practices and procedures intothe templates. Teamcenter users initiate workflow processes using these templates.

worldAll users regardless of group or role.


Index

AAccess

To classify workspace objects,controlling . . . . . . . . . . . . . . . . . 9-57

Access control entry (ACE) . . . . . . . . . . . 2-4Access control examples . . . . . . . . . . . . 10-5Access control list (ACL) . . . . . . . . . . . . 2-4Access control lists . . . . . . . . . . . . . . . . 2-5

Bypass . . . . . . . . . . . . . . . . . . 2-10–2-11Import/Export . . . . . . . . . . . . . . 2-10, 6-1Item Revs . . . . . . . . . . . . . . . . . . . . 2-12Items . . . . . . . . . . . . . . . . . . . . . . . 2-12Scheduling Cost Objects . . . . . . . . . . . 5-2Scheduling Execution Objects . . . . . . . 5-2Scheduling Objects . . . . . . . . . . . . . . . 5-2Vault . . . . . . . . . . . . . . . . . . . 2-10–2-11Working . . . . . . . . . . . . . . . . . . . . . 2-12

Access Control pane . . . . . . . . . . 10-8–10-9Access Control tab . . . . . . . . . . . 10-8, 10-10Access Manager

Cautions for using . . . . . . . . . . . . . . 2-15Controlling revision rules . . . . . . . . . . 3-7Creating access rules . . . . . . . . . . . . 10-8Description . . . . . . . . . . . . . . . . . . . 10-1Editing Classification rules . . . . . . . . 10-4Enhanced multi-site security . . . . . . 2-17Privileges . . . . . . . . . . . . . . . . . . . . 10-4Rules . . . . . . . . . . . . . . . . . . . . . . . 9-36

Access privileges . . . . . . . . . . . . . 10-4, A-11Accessor precedence . . . . . . . . . . . . . . A-9Accessor types . . . . . . . . . . . . . . . . . . A-9Accessors . . . . . . . . . . . . . . . . . . . . . . A-9

Approver . . . . . . . . . . . . . . . . . . 4-2, A-8Approver (Group) . . . . . . . . . . . . . . . . 4-2Approver (RIG) . . . . . . . . . . . . . . . . . 4-1Approver Group . . . . . . . . . . . . . . . . A-8Approver RIG . . . . . . . . . . . . . . . . . A-8Approver Role . . . . . . . . . . . . . . . . . A-8Current project team . . . . . . . . . . . . A-8Current project teams . . . . . . . . 8-8, A-8Current Project Teams . . . . . . . . . . . . 8-8Group . . . . . . . . . . . . . . . . . . . . . . . A-7Group administrator . . . . . . . . . . . . A-7Groups with security . . . . . . . . . 7-2, A-7

Groups with Security . . . . . . . . . . . . . 7-2Owner (owning user) . . . . . . . . . . . . A-7Owning group . . . . . . . . . . . . . . 7-2, A-7Owning Group . . . . . . . . . . . . . . . . . . 7-2Project team . . . . . . . . . . . . . . . . . . A-8Project teams . . . . . . . . . . . . . . . 8-8, A-8Project Teams . . . . . . . . . . . . . . . . . . 8-8Public schedule . . . . . . . . . . . . . . . . A-8Remote site . . . . . . . . . . . . . . . . . . . A-7Responsible party . . . . . . . . . . . . . . A-8Responsible Party . . . . . . . . . . . . . . . 4-2Role . . . . . . . . . . . . . . . . . . . . . . . . A-7Role in group . . . . . . . . . . . . . . . . . . A-7Role in owning group . . . . . . . . . . . . A-7Role in project . . . . . . . . . . . . . 8-11, A-8Role in projects of object . . . . . . 8-11, A-8Site . . . . . . . . . . . . . . . . . . . . . . . . . A-7System administrator . . . . . . . . . . . . A-7Task owner . . . . . . . . . . . . . . . . . . . A-8Task Owner . . . . . . . . . . . . . . . . . . . . 4-2Task owning group . . . . . . . . . . . . . . A-8Task Owning Group . . . . . . . . . . . . . . 4-2User . . . . . . . . . . . . . . . . . . . . . . . . A-7User Excluded . . . . . . . . . . 9-6, 9-39, A-9User Has Government Clearance . . . 9-39,

A-9User has IP clearance . . . . . . . . . . . . . 9-6User Has IP Clearance . . . . . . . . 9-6, A-9User In License . . . . . . . . . . . . . A-8–A-9User IP Licensed . . . . . . . . . . . . 9-6, A-9User IP Unlicensed . . . . . . . . . . 9-6, A-9User ITAR Licensed . . . . . . . . . 9-39, A-9User ITAR Unlicensed . . . . . . . 9-39, A-9User Not In License . . . . . . . . . . A-8–A-9User Over Government Clearance . . 9-39,

A-9User Over IP Clearance . . . . . . . 9-6, A-9User Under Government

Clearance . . . . . . . . . . . . . . 9-39, A-9User Under IP Clearance . . . . . . 9-6, A-9World . . . . . . . . . . . . . . . . . . . . . . . A-7

ACE (access control entry) . . . . . . . . . . . 2-4ACL (access control list) . . . . . . . . . . . . . 2-4ACL Name box . . . . . . . . . . . . . . . . . . 10-9

PLM00101 I Security Administration Guide Index-1

Index

ACL, working . . . . . . . . . . . . . . . . . . . . 3-2Add Content privilege . . . . . . . . . . . . . A-15Add New ACL button . . . . . . . . . . . . . 10-9Administer ADA privilege . . . . . . . . . . A-14Applications

Access Manager . . . . . . . . . . . . 10-1, 10-4Approver . . . . . . . . . . . . . . . . . . . . . . A-8

Group . . . . . . . . . . . . . . . . . . . . . . . A-8RIG . . . . . . . . . . . . . . . . . . . . . . . . A-8Role . . . . . . . . . . . . . . . . . . . . . . . . A-8

Approver (Group) accessor . . . . . . . . . . . 4-2Approver (RIG) accessor . . . . . . . . . . . . 4-1Approver accessor . . . . . . . . . . . . . . . . . 4-2Assign to project privilege . . . . . . . . . . A-12Authentication . . . . . . . . . . . . . . . . . . . 2-2Authorization . . . . . . . . . . . . . . . . . . . . 2-3Authorized data access . . . . . 2-16, 9-1, 9-32

Intellectual property (IP) . . . . . . . . . . 9-2License propagation . . . . . . . . . . 9-8, 9-46

Authorized data access (IP)Multi-Site Collaboration

considerations . . . . . . . . . . . . . . . 9-23NX security for classified data . . . . . 9-21,

9-49Rule placement . . . . . . . . . . . . . . . . 9-21Rule precedence . . . . . . . . . . . . . . . . 9-21

Authorized data access (IP) basictasks . . . . . . . . . . . . . . . . . . . . . . . . 9-24Assigning classification values . . . . . 9-30Assigning IP Admin role and

privileges . . . . . . . . . . . . . . . . . . 9-26Assigning user clearance levels . . . . . 9-30Associating licenses with data . . . . . . 9-31Configuring logging and blocking for

NX . . . . . . . . . . . . . . . . . . . 9-25, 9-53Creating IP licenses . . . . . . . . . . . . . 9-30Defining IP clearance and classification

levels . . . . . . . . . . . . . . . . . . . . . 9-25Enabling authorized data access . . . 9-25,

9-53Authorized data access (ITAR) . . . 9-34–9-36

NX security for classified data . . . . . 9-21,9-49

Rule precedence . . . . . . . . . . . . . . . . 9-21Authorized data access (ITAR) basictasks . . . . . . . . . . . . . . . . . . . . . . . . 9-52Applying Access Manager rules . . . . . 9-61Assigning clearance level . . . . . . . . . 9-58Assigning geographic location to

sites . . . . . . . . . . . . . . . . . . . . . . 9-59Assigning geographic location to

users . . . . . . . . . . . . . . . . . . . . . 9-58Assigning government classification

values . . . . . . . . . . . . . . . . . . . . 9-60

Assigning ITAR Admin role andprivileges . . . . . . . . . . . . . . . . . . 9-55

Assigning nationality to groups . . . . . 9-59Assigning nationality to users . . . . . . 9-58Assigning technology transfer certification

dates . . . . . . . . . . . . . . . . . . . . . 9-58Associating licenses with data . . . . . . 9-61Creating ITAR licenses . . . . . . . . . . . 9-60Defining ITAR clearance and classification

levels . . . . . . . . . . . . . . . . . . . . . 9-54Authorized data access (ITAR)examples . . . . . . . . . . . . . . . . . . . . . 9-46

Authorized data access (ITAR) implementationconsiderationsMulti-Site Collaboration . . . . . . . . . . 9-51Rule placement . . . . . . . . . . . . . . . . 9-49

BBasic concepts . . . . . . . . . . . . . . . . . . . 2-1Basic tasks

Authorized data access (IP) . . . . . . . . 9-24Authorized data access (ITAR) . . . . . 9-52

Batch Print privilege . . . . . . . . . . . . . . A-14Boxes

ACL Name . . . . . . . . . . . . . . . . . . . 10-9Buttons

Add New ACL . . . . . . . . . . . . . . . . . 10-9

CCautionary statements for usingrules . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Change ownership privilege . . . . . . . . . A-12Change privilege . . . . . . . . . . . . . . . . . A-12Change privilege, guidelines . . . . . . . . . 3-4CICO privilege . . . . . . . . . . . . . . . . . . A-14Citizenship . . . . . . . . . . . . . . . . . . . . . 9-34Citizenship On Any ADA Liccondition . . . . . . . . . . . . . . . . . . . . . . 9-38

Citizenship On Any Exclude Liccondition . . . . . . . . . . . . . . . . . . . . . . 9-39

Citizenship On Any IP Lic condition . . . 9-39Citizenship On Any ITAR Liccondition . . . . . . . . . . . . . . . . . . . . . . 9-39

Classification . . . . . . . . . . . . . . . . . . . . 9-2Access Control feature . . . . . . . . . . . 10-4Access privileges . . . . . . . . . . . . . . . 10-4

Classification AdministrationRestrictions . . . . . . . . . . . . . . . . . . . 10-4

Classification and licensingapproaches . . . . . . . . . . . . . . . . . . . . . 9-6

Classifying workspace objectsControlling access to . . . . . . . . . . . . 9-57

Index-2 Security Administration Guide PLM00101 I

Index

Clearance . . . . . . . . . . . . . . . . . . . . . . . 9-2Columns

ID of Accessor . . . . . . . . . . . . . . . . . 10-9Privilege . . . . . . . . . . . . . . . . . . . . . 10-9Type of Accessor . . . . . . . . . . . . . . . 10-9

Component display suppression . . . . . . 10-1Compound property

controlling access based on . . . . . . . . 11-1Conditions . . . . . . . . . . . . . . . . . . . . . A-1

Citizenship On Any ADA Lic . . . . . . . 9-38Citizenship On Any Exclude Lic . . . . 9-39Citizenship On Any IP Lic . . . . . . . . 9-39Citizenship On Any ITAR Lic . . . . . . 9-39Group Nationality . . . . . . . . . . . . . . 9-37Has Government Classification . . . . . 9-37Has IP Classification . . . . . . . . . . . . . 9-4Has Named Exclude License . . . . . . . . 9-5Has Named IP License . . . . . . . . . . . . 9-5Has Named ITAR License . . . . . . . . . 9-38Has No Government Classification . . 9-37Has No IP Classification . . . . . . . . . . . 9-4In Current Project . . . . . . . . . . . . . . . 8-7In Job . . . . . . . . . . . . . . . . . . . . . . . . 4-1In Project . . . . . . . . . . . . . . . . . . . . . 8-7Is User On IP License . . . . . . . . . . . . . 9-4Owning Group . . . . . . . . . . . . . . . . . . 7-2Owning Group Has Security . . . . . . . . 7-1Site Geography . . . . . . . . . . . . . . . . 9-37User Geography . . . . . . . . . . . . . . . . 9-37User Has Government Clearance . . . . 9-38User Has IP Clearance . . . . . . . . . . . . 9-3User In Attached Exclude License . . . . 9-5User In Attached ITAR License . . . . . 9-38User In License . . . . . . . . . . . . . . . . 9-38User In Named Exclude License . . . . . 9-6User In Named IP License . . . . . . . . . 9-5User In Named ITAR License . . . . . . 9-38User Is Excluded . . . . . . . . . . . . . . . . 9-4User Is IP Licensed . . . . . . . . . . . . . . 9-4User Is ITAR Licensed . . . . . . . . . . . 9-37User Nationality . . . . . . . . . . . . . . . 9-36User TTC Expired . . . . . . . . . . . . . . 9-38

Configuring security for special projectdata . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Configuring supplier security . . . . . . . . . 7-3Configuring supplier security for externaldata . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Configuring supplier security for internaldata . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Controlling accessTo classify workspace objects . . . . . . . 9-57

Controlling access based on compoundproperty values . . . . . . . . . . . . . . . . . 11-1

Controlling access to Classificationobjects . . . . . . . . . . . . . . . . . . . . . . . 10-1

Creating effectivity . . . . . . . . . . . . . . . 2-17Current

Project team . . . . . . . . . . . . . . . . . . A-8Project teams . . . . . . . . . . . . . . . 8-8, A-8

Current Project Teams accessor . . . . . . . 8-8

DData security . . . . . . . . . . . . . . . . . . . 9-32Delete privilege . . . . . . . . . . . . . . . . . . A-11

Guidelines . . . . . . . . . . . . . . . . . . . . . 3-4Demote privilege . . . . . . . . . . . . . 4-2, A-12Deny privilege option . . . . . . . . 10-9–10-10Dialog boxes

Select Accessor . . . . . . . . . . . . . . . . 10-9Digital Sign privilege . . . . . . . . . . . . . . A-14

EEditing effectivity . . . . . . . . . . . . . . . . . 3-2Effective ACL example . . . . . . . . . . . . . 2-8Effectivity . . . . . . . . . . . . . . . . . . . . . 2-17

Creating . . . . . . . . . . . . . . . . . . . . . 2-17Editing . . . . . . . . . . . . . . . . . . . . . . 2-17Example of . . . . . . . . . . . . . . . . . . . . 3-8

Effectivity and access control . . . . . . . . 2-17Enhanced multi-site security . . . . . . . . 2-17EPM-set-rule-based-protectionhandler . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Examples, access controls . . . . . . . . . . 10-5Exclude licenses . . . . . . . . . . . . . . . 9-1, 9-3Export privilege . . . . . . . . . . . . . . . . . A-12External groups . . . . . . . . . . . . . . . . . . 7-3

GGeography . . . . . . . . . . . . . . . . . . . . . 9-34Getting started . . . . . . . . . . . . . . . . . . . 1-1Government classification . . . . . . . . . . 9-34Government clearance . . . . . . . . . . . . . 9-34Grant privilege option . . . . . . . . 10-9–10-10Group . . . . . . . . . . . . . . . . . . . . . . . . A-7

Administrator . . . . . . . . . . . . . . . . . A-7Group Nationality condition . . . . . . . . . 9-37Group-level security . . . . . . . . . . . 2-16, 7-1

Configuring for suppliers . . . . . . . 7-2–7-3External groups . . . . . . . . . . . . . . . . . 7-3Hierarchical groups . . . . . . . . . . . 7-3–7-4Internal groups . . . . . . . . . . . . . . . . . 7-2

Groups . . . . . . . . . . . . . . . . . . . . . 2-16, 7-1Rule conditions . . . . . . . . . . . . . . . . . 7-1


Index

Groups with security . . . . . . . . . . . 7-2, A-7Groups with Security accessor . . . . . . . . 7-2

H

Has Government Classificationcondition . . . . . . . . . . . . . . . . . . . . . . 9-37

Has IP Classification condition . . . . . . . . 9-4Has Named Exclude License Licensedcondition . . . . . . . . . . . . . . . . . . . . . . . 9-5

Has Named IP License Licensedcondition . . . . . . . . . . . . . . . . . . . . . . . 9-5

Has Named ITAR License condition . . . 9-38Has No Government Classificationcondition . . . . . . . . . . . . . . . . . . . . . . 9-37

Has No IP Classification condition . . . . . 9-4Has property condition . . . . . . . . . . . . 11-1Hierarchical group security . . . . . . . 7-3–7-4Hierarchy component protection . . . . . . 10-1Hierarchy tab . . . . . . . . . . . . . . 10-8, 10-10

I

ICO protection . . . . . . . . . . . . . . . . . . 10-2ID of Accessor column . . . . . . . . . . . . . 10-9Import privilege . . . . . . . . . . . . . . . . . A-12Import/Export ACL . . . . . . . . . . . . . . . . 6-1In Current Program rule . . . . . . . . . . . . 8-4In Current Project condition . . . . . . . . . . 8-7In Inactive Program rule . . . . . . . . . . . . 8-4In Invisible Program rule . . . . . . . . . . . . 8-5In Job condition . . . . . . . . . . . . . . . . . . 4-1In Project condition . . . . . . . . . . . . . . . . 8-7In-process data . . . . . . . . . . . . . . . . . . . 4-1Inactive Program ACL . . . . . . . . . . . . . . 8-4InAnySchedule . . . . . . . . . . . . . . . . . . A-9InSchedule . . . . . . . . . . . . . . . . . . . . . A-8Intellectual property

Access rules . . . . . . . . . . . . . . . . . . . . 9-3Classification . . . . . . . . . . . . . . . . . . . 9-2Classification and licensing . . . . . . . . . 9-6Clearance . . . . . . . . . . . . . . . . . . . . . 9-2Licenses . . . . . . . . . . . . . . . . . . . . . . 9-2

Intellectual property (IP) classification . . 9-2Intellectual property (IP) clearance . . . . . 9-2Intellectual property (IP) licenses . . . 9-2–9-3Intellectual property authorized dataaccess . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Dataset-level implementation . . . . . . 9-18Group implementation . . . . . . . . . . . 9-13Role and project implementation . . . . . 9-8

Intended audience . . . . . . . . . . . . . . . . . 1-1Internal groups . . . . . . . . . . . . . . . . . . . 7-2

International Traffic in Arms Regulations(ITAR) . . . . . . . . . . . . . . . . . . . . . . . 9-32

Invisible Program ACL . . . . . . . . . . . . . 8-5IP Admin privilege . . . . . . . . . . . . . . . A-13IP Classifier privilege . . . . . . . . . . . . . A-14IP licenses . . . . . . . . . . . . . . . . . . . 9-1–9-2Is Owned By Program rule . . . . . . . . . . . 8-6Is Program Member rule . . . . . . . . . . . . 8-4Is User In Named Exclude Licensecondition . . . . . . . . . . . . . . . . . . . . . . . 9-6

Is User On IP License condition . . . . . . . 9-4ITAR . . . . . . . . . . . . . . . . . . . . . . . . . 9-32

Access Manager rules . . . . . . . . . . . . 9-36ITAR Admin privilege . . . . . . . . . 9-36, A-13ITAR Classifier privilege . . . . . . . 9-36, A-15ITAR license . . . . . . . . . . . . . . . . . . . . 9-35ITAR licenses . . . . . . . . . . . . . . . . . . . . 9-1

L

LicensesExclude . . . . . . . . . . . . . . . . . . . . . . . 9-1IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1ITAR . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Licensing . . . . . . . . . . . . . . . . . . . . . . . 2-2Lists

Named ACL . . . . . . . . . . . . . . . . . 10-10

M

Master form permissions . . . . . . . . . . . . 2-2Multi-Site Collaboration

Remote checkout privilege . . . . . . . . 2-18

N

Named ACL list . . . . . . . . . . . . . . . . 10-10Nationality . . . . . . . . . . . . . . . . . . . . . 9-34Not Current Program ACL . . . . . . . . . . . 8-4Not Program Member ACL . . . . . . . . . . 8-4

O

Object model hierarchy . . . . . . . . . . . . . 2-1Object-based protection . . . . . . . . . . . . . 2-4Options

Deny privilege . . . . . . . . . . . . 10-9–10-10Grant privilege . . . . . . . . . . . 10-9–10-10

Organization . . . . . . . . . . . . . . . . . . . 9-35Overriding write access of remoteobjects . . . . . . . . . . . . . . . . . . . . . . . 2-18

Owner (owning user) . . . . . . . . . . . . . . A-7Owning group . . . . . . . . . . . . . . . . 7-2, A-7


Index

Owning Group accessor . . . . . . . . . . . . . 7-2Owning Group condition . . . . . . . . . . . . 7-2Owning Group Has Security condition . . 7-1

PPanes

Access control . . . . . . . . . . . . . . . . . 10-8Access Control . . . . . . . . . . . . . 10-8–10-9

Parallel task and parallel process ACL conflictresolution . . . . . . . . . . . . . . . . . . . . . . 4-3

Permissions for master forms . . . . . . . . . 2-2Prerequisites . . . . . . . . . . . . . . . . . . . . 1-1Privilege column . . . . . . . . . . . . . . . . . 10-9Privileges

Add Content . . . . . . . . . . . . . . . . . . A-15Administer ADA license . . . . . . . . . . A-14Assign to project . . . . . . . . . . . . . . . A-12Batch Print . . . . . . . . . . . . . . . . . . . A-14Change . . . . . . . . . . . . . . . . . . 3-4, A-12Change ownership . . . . . . . . . . . . . . A-12CICO . . . . . . . . . . . . . . . . . . . . . . . A-14Delete . . . . . . . . . . . . . . . . . . . 3-4, A-11Demote . . . . . . . . . . . . . . . . . . 4-2, A-12Digital Sign . . . . . . . . . . . . . . . . . . . A-14Export . . . . . . . . . . . . . . . . . . . . . . A-12Import . . . . . . . . . . . . . . . . . . . . . . A-12IP Admin . . . . . . . . . . . . . . . . . . . . A-13IP Classifier . . . . . . . . . . . . . . . . . . A-14ITAR Admin . . . . . . . . . . . . . . . . . . A-13ITAR Classifier . . . . . . . . . . . . . . . . A-15Promote . . . . . . . . . . . . . . . . . 4-2, A-12Publish . . . . . . . . . . . . . . . . . . . . . . A-12Read . . . . . . . . . . . . . . . . . . . . . . . . A-11Remote checkout . . . . . . . . . . . . . . . A-13Remove Content . . . . . . . . . . . . . . . A-15Remove from project . . . . . . . . . . . . . A-13Subscribe . . . . . . . . . . . . . . . . . . . . A-12Transfer in . . . . . . . . . . . . . . . . . . . A-12Transfer out . . . . . . . . . . . . . . . . . . A-12Translation . . . . . . . . . . . . . . . . . . . A-14Unmanage . . . . . . . . . . . . . . . . . . . A-13View/Markup . . . . . . . . . . . . . . . . . . A-14Write . . . . . . . . . . . . . . . . . . . . . . . A-11Write Classification ICO . . . . . . . . . . A-12

Program-level securityAccess rules . . . . . . . . . . . . . . . . . . . . 8-2Default access rules . . . . . . . . . . . . . . 8-3In Current Program rule . . . . . . . . . . 8-4In Inactive Program rule . . . . . . . . . . 8-4In Invisible Program rule . . . . . . . . . . 8-5Inactive Program ACL . . . . . . . . . . . . 8-4Invisible Program ACL . . . . . . . . . . . . 8-5Is Owned By Program rule . . . . . . . . . 8-6

Is Program Member rule . . . . . . . . . . . 8-4Not Current Program ACL . . . . . . . . . 8-4Not Program Member ACL . . . . . . . . . 8-4Projects ACL . . . . . . . . . . . . . . . . . . . 8-6

ProjectTeam . . . . . . . . . . . . . . . . . . . . . . . A-8Teams . . . . . . . . . . . . . . . . . . . . 8-8, A-8

Project Objects ACL . . . . . . . . . . . . . . . 8-6Project Teams accessor . . . . . . . . . . . . . 8-8Project-level rules . . . . . . . . . . . . . . . . 8-17Project-level security . . . . . . . . . . . . . . 2-16

Access rules . . . . . . . . . . . . . . . . . . . . 8-2Default access rules . . . . . . . . . . . . . . 8-3Implementation considerations . . . . . 8-17Multiple project access examples . . . . 8-14Multiple supplier access examples . . . 8-16Project Objects ACL . . . . . . . . . . . . . . 8-6Projects ACL . . . . . . . . . . . . . . . . . . . 8-5Role-based access . . . . . . . . . . . . . . . 8-10Role-based access examples . . . . . . . 8-11Rule placement . . . . . . . . . . . . . . . . 8-17User-based access . . . . . . . . . . . . . . . 8-7User-based access examples . . . . . . . . 8-8

Project-level security implementationconsiderations . . . . . . . . . . . . . . . . . . 8-17

Project-level security tasksApplying Access Manager rules . . . . . . 8-2

Projects . . . . . . . . . . . . . . . . . . . . . . . . 8-6Projects ACL . . . . . . . . . . . . . . . . . . . . 8-5Promote privilege . . . . . . . . . . . . 4-2, A-12Public schedule . . . . . . . . . . . . . . . . . . A-8Publish privilege . . . . . . . . . . . . . . . . . A-12

RRead privilege . . . . . . . . . . . . . . . . . . . A-11Remote checkout . . . . . . . . . . . . . . 2-18, 6-1Remote checkout of unmodifiableobjects . . . . . . . . . . . . . . . . . . . . . . . 2-18

Remote checkout privilege . . . . . . . . . . A-13Remote export . . . . . . . . . . . . . . . . . . . 6-1Remote site . . . . . . . . . . . . . . . . . . . . A-7Remote workflow ACL . . . . . . . . . . . . . . 6-1Remove Content privilege . . . . . . . . . . A-15Remove from project privilege . . . . . . . A-13Responsible party . . . . . . . . . . . . . . . . A-8Responsible Party accessor . . . . . . . . . . . 4-2Restrictions . . . . . . . . . . . . . . . . . . . . 10-4Revision rules

Controlling access . . . . . . . . . . . . . . . 3-7Role . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

In group . . . . . . . . . . . . . . . . . . . . . A-7In owning group . . . . . . . . . . . . . . . . A-7In project . . . . . . . . . . . . . . . . 8-11, A-8


Index

In projects of object . . . . . . . . . . . . . A-8In projects of objects . . . . . . . . . . . . . 8-11InAnySchedule . . . . . . . . . . . . . . . . A-9InSchedule . . . . . . . . . . . . . . . . . . . A-8

Rule tree . . . . . . . . . . . . . . . . . . . . . . . 2-5Conditions . . . . . . . . . . . . . . . . . . . . A-1

Rule tree precedence . . . . . . . . . . . . . . . 2-5Rules

Cautionary statements . . . . . . . . . . . 2-15Definition . . . . . . . . . . . . . . . . . . 2-3, 2-6Example . . . . . . . . . . . . . . . . . . . . . 2-11Subbranch precedence . . . . . . . . . . . . 2-5Syntax . . . . . . . . . . . . . . . . . . . . . . . 2-6Tips for using . . . . . . . . . . . . . . . . . 2-13Tree . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Rules-based protection . . . . . . . . . . . 2-3, 2-6

SSchedule Manager . . . . . . . . . . . . . . . . . 5-1Scheduling Cost Objects ACL . . . . . . . . . 5-2Scheduling data . . . . . . . . . . . . . . . . . . 5-1

Rule tree . . . . . . . . . . . . . . . . . . . . . . 5-1Scheduling Execution Objects ACL . . . . . 5-2Scheduling Objects ACL . . . . . . . . . . . . 5-2Security Services . . . . . . . . . . . . . . . . . 2-2Select Accessor dialog box . . . . . . . . . . 10-9Site . . . . . . . . . . . . . . . . . . . . . . . . . . A-7Site Geography condition . . . . . . . . . . . 9-37Special behavior of remote checkout . . . 2-18Subscribe privilege . . . . . . . . . . . . . . . A-12Supplier security . . . . . . . . . . . . . . . . . 2-16System administrator . . . . . . . . . . . . . A-7

TTabs

Access Control . . . . . . . . . . . . 10-8, 10-10Hierarchy . . . . . . . . . . . . . . . 10-8, 10-10

Task owner . . . . . . . . . . . . . . . . . . . . . A-8Task Owner accessor . . . . . . . . . . . . . . . 4-2Task owning group . . . . . . . . . . . . . . . A-8Task Owning Group accessor . . . . . . . . . 4-2TC_check_remote_user_priv_from_sites . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Teamcenter security applications . . . . . . 1-1Technical Assistance Agreement . . . . . . 9-35Technology Transfer CertificationDate . . . . . . . . . . . . . . . . . . . . . . . . . 9-35

Tips for using rules . . . . . . . . . . . . . . . 2-13Transfer in privilege . . . . . . . . . . . . . . A-12Transfer out privilege . . . . . . . . . . . . . A-12Translation privilege . . . . . . . . . . . . . . A-14Type of Accessor column . . . . . . . . . . . 10-9Type-level rules . . . . . . . . . . . . . . . . . 8-17

UUnmanage privilege . . . . . . . . . . . . . . A-13User . . . . . . . . . . . . . . . . . . . . . . . . . A-7User Excluded . . . . . . . . . . . . . . . . . . A-9User Excluded accessor . . . . . . . . . 9-6, 9-39User Geography condition . . . . . . . . . . 9-37User Has Government Clearance . . . . 9-39,A-9

User Has Government Clearanceaccessor . . . . . . . . . . . . . . . . . . . . . . 9-39

User Has Government Clearancecondition . . . . . . . . . . . . . . . . . . . . . . 9-38

User Has IP Clearance . . . . . . . . . . . . A-9User has IP clearance accessor . . . . . . . . 9-6User Has IP Clearance accessor . . . . . . . 9-6User Has IP Clearance condition . . . . . . 9-3User In Attached Exclude Licensecondition . . . . . . . . . . . . . . . . . . . . . . . 9-5

User In Attached ITAR Licensecondition . . . . . . . . . . . . . . . . . . . . . . 9-38

User In License . . . . . . . . . . . . . . . A-8–A-9User In License condition . . . . . . . . . . 9-38User In Named IP License condition . . . . 9-5User In Named ITAR Licensecondition . . . . . . . . . . . . . . . . . . . . . . 9-38

User IP Licensed . . . . . . . . . . . . . . . . . A-9User IP Licensed accessor . . . . . . . . . . . 9-6User IP Unlicensed . . . . . . . . . . . . . . . A-9User IP Unlicensed accessor . . . . . . . . . . 9-6User Is Excluded condition . . . . . . . . . . . 9-4User Is IP Licensed condition . . . . . . . . . 9-4User Is ITAR Licensed condition . . . . . 9-37User ITAR Licensed . . . . . . . . . . 9-39, A-9User ITAR Licensed accessor . . . . . . . . 9-39User ITAR Unlicensed . . . . . . . . . 9-39, A-9User ITAR Unlicensed accessor . . . . . . 9-39User Nationality condition . . . . . . . . . . 9-36User Not In License . . . . . . . . . . . A-8–A-9User Over Government Clearance . . . . A-9User Over Government Clearanceaccessor . . . . . . . . . . . . . . . . . . . . . . 9-39

User Over IP Clearance . . . . . . . . . . . . A-9User Over IP Clearance accessor . . . . . . 9-6User TTC Expired condition . . . . . . . . . 9-38User Under Government Clearance . . 9-39,A-9

User Under Government Clearanceaccessor . . . . . . . . . . . . . . . . . . . . . . 9-39

User Under IP Clearance . . . . . . . . . . . A-9User Under IP Clearance accessor . . . . . 9-6

VView/Markup privilege . . . . . . . . . . . . A-14


Index

W

Workflow accessorsApprover . . . . . . . . . . . . . . . . . . . . . . 4-2Approver (Group) . . . . . . . . . . . . . . . . 4-2Approver (RIG) . . . . . . . . . . . . . . . . . 4-1Approver (Role) . . . . . . . . . . . . . . . . . 4-2Responsible Party . . . . . . . . . . . . . . . 4-2Task Owner . . . . . . . . . . . . . . . . . . . . 4-2Task Owning Group . . . . . . . . . . . . . . 4-2

Workflow ACL examples . . . . . . . . . . . . 4-2Workflow privileges

Demote . . . . . . . . . . . . . . . . . . . . . . . 4-2

Promote . . . . . . . . . . . . . . . . . . . . . . 4-2Working ACL . . . . . . . . . . . . . . . . 2-12, 3-2Working data . . . . . . . . . . . . . . . . . . . . 3-1

Controlling access to effectivityexample . . . . . . . . . . . . . . . . . . . . 3-8

Rule tree example . . . . . . . . . . . . . . . 3-4Workspace objects

Configuring access to classify . . . . . . 9-57World . . . . . . . . . . . . . . . . . . . . . . . . . A-7Write access to release objects . . . . . . . 2-18Write Classification ICO privilege . . . . . A-12Write privilege . . . . . . . . . . . . . . . . . . A-11


security administration guide -...

Documents