The following components make up the security model:
Domains and data segregation
Authoring tools, such as Intergraph Smart P&ID and Smart 3D, each publish their own data, which is then consolidated on approval. The data sets published by the authoring tools need to be segregated and managed independently of each other and independently from the consolidated data set. Each of these data sets is referred to as a domain. Domains are also used to segregate the data sets for the schema, system administration, and central SmartPlant Foundation data. The role definition determines which domains a user can access. For more information about data access and domains, see Data access configuration.
Domains segregate the data in the database for both performance and data integrity.
Domains are also used by SmartPlant Foundation authoring to segregate the data in a similar way to the tool database of applications like Smart P&ID. The SmartPlant Foundation authoring tools create their data in one domain and publish into a second domain. For more information about the use of domains in an integrated tool environment, see Domain configuration for data segregation.
Configurations
Configurations are used to manage controlled change to data. The top-level configurations are usually plants with projects beneath them. Objects created in one configuration are not visible from parallel or higher configurations. For example, data created in Project1 is not visible in Project2 or at the plant level.
Projects are used to perform staged changes to the plant. Objects are claimed from the plant to the project to be modified and new items created in the project. When changes are approved, they are merged up to the plant. Configurations are relevant to the security model in that:
-
A user can be assigned different roles in different configurations.
-
A user can query across multiple configurations. These are known as query configurations.
-
A user creates and manipulates data in a single configuration. This is known as the “create configuration” and must be one of the selected query configurations.
Configurations slice the data in a different way than domains. If domains are vertical splits of data, then the configurations are horizontal.
Not all objects are configuration controlled:
-
If a class definition is defined as not configuration controlled, then objects of that class definition are always created with no configuration.
-
If a class definition is defined as configuration controlled, then objects of that class definition can be created in a configuration or with no configuration. For example, a Designer may create a folder in Project1, but a system administrator with no access to projects would create a configuration independent folder for their use. To create a configuration independent item, the user sets the create configuration to Scope Not Set.
A separate concurrent engineering guide describes this in more detail.
Access groups
Access groups determine what actions a user can perform in the system. They control a user’s level of access to a particular functional component of the system, such as the following:
-
DocumentView
-
TransmittalUpdate
-
InstallationAdmin
The full set of delivered access groups are detailed in How to Configure the Security Model.
The user is related to the access groups through a role. Roles control:
-
Conditional access to menu commands and toolbar buttons
-
Conditional access to object shortcut menu commands
-
Conditional access to relationship creation and navigation
Owning groups
SmartPlant Foundation has two ownership relationships. You can configure an object to be owned by a user or by an owning group, which is why groups are more commonly referred to as owning groups. The link between users and owning groups is not a simple relationship; it is via the user's role.
Owning groups are typically configured to set up ownership of data by department or discipline.
Owning groups can be used to control the user’s access to an object or parts of an object based on its ownership. This control operates independently of domains and configurations, both within and across multiple domains and configurations. Access control by object ownership can be configured to control the following:
-
Shortcut menu command access (for example, check out of a document)
-
Menus and toolbar access (for example, for the process group)
-
Query access to objects (for example, documents)
Roles and role assignments
Users perform different roles in different configurations (different plants or projects). A user can perform a different role in two different projects at the same time. For this reason, a role is made up of different sets of access groups, domains, and owning groups, and these sets are used separately when determining user access to the system.
-
Roles determine the user’s level of access in the system based on related access groups.
-
Roles determine the domains accessed (queried) by a user.
-
Roles determine the access to different data, based on owning groups configured on the role.
-
Role assignments are configured by a dedicated GUI.