Access and Authorization

Overview

AspenTech Inmation has a rights & roles concept, that requires configuration of the Access Model and assigning object level security to other models. As such, profiles have to be created, which are described in the following concept. The profiles need to be linked to objects in the different models with security references. User accounts are not configured in the access model; they are managed in Active Directory through groups. Active Directory groups are linked to profile objects.

Security principles for GXPC deployment

For the GXPC deployment, the configuration follows the following principles. The design of the security configuration, and the configuration instructions ensure that the principles are not violated.

Authentication

End user authentication is always using Windows users from a corporate Active Directory. AspenTech Inmation authentication is not used for end users.

There is an emergency user, for access in case of an active directory outage.

Machine authentication can use AspenTech Inmation authentication. This is meant for software-to-software authentication.

Configuring Access Model

The access model is available only to administrative profiles. Operations, such as creating / deleting / modifying objects in the access model, are not possible to an end user. Configuration is done with the support of the Lua library esi-security.

An important part of the security reference functionality is that explicit permissions overwrite ALL implicit permissions that have been inherited. This means for example, that creating references for a Local-Core object also changes inherited permissions from profiles with references in parent objects.

There are 2 different points in time, when profiles / references can be created:

  • During deployment of a Master- or Local-Core server, a default set of profiles is created.

  • Usecase specific profiles / groups, with a dedicated access level for a special usecase.

Security Descriptors

The following security descriptors exist in the system. They are used when security references are attached to objects.

Read

Read properties and current value / event

Write

Write current value

Modify

Modify properties, Create, Delete, Enable, Disable

Inherit

Descriptors also apply to subtree, till other explicit permission is set.

List

Object will appear when listing the parent’s children.

Access Matrix

An Access Matrix is a security model of protection state in computer systems that identifies the rights of each subject to each object in the system. Each row corresponds to a subject (profile). Each column corresponds to an object (AspenTech Inmation permission). Each cell corresponds to the prescence or absence of a right. It indicates whether a subject should have the right to an object.

Role

General Authorization

Model Authorization

Audit Trail Roles

DataStudio

External API

I/O Model

KPI Model

Access Model

Server Model

ISA-95 Equipment Model

Administrator

System-wide Reviewer

Limited Reviewer

System-Administrators

Administrator

y

Global-Administrators

y

y

y

y

y

Global-Auditors

y

y

y

y

y

y

Global-Engineers

y

y

y

y

y

y

Global-Readers

y

y

y

y

Global-Writers

y

y

y

y

y

SITE-Administrators

y

y

y

y

y

y

SITE-Auditors

y

y

y

y

y

y

SITE-Engineers

y

y

y

y

y

y

SITE-Readers

y

y

y

y

SITE-Writers

y

y

y

y

y

Site Profiles

The following profiles exist for site level. They are created when a Local-Core is deployed, as per the configuration instructions:

SITECODE-Readers

This profile has the least amount of permissions, and can’t change or modify objects. DataStudio access is deactivated. It has the following descriptors set:

  • List / Read on object Local-Core for this site

  • List / Read on object Site (KPI Model)

  • List / Read on object Site (ISA95 Model)

References are inherited to the subtree of the objects mentioned above.

SITECODE-Engineers

This profile has the least amount of permissions, and can’t change or modify objects. DataStudio access is possible. Audit trail is visible. It has the following descriptors set:

  • List / Read on object Local-Core for this site

  • List / Read on object Site (KPI Model)

  • List / Read on object Site (ISA95 Model)

References are inherited to the subtree of the objects mentioned above.

SITECODE-Writers

As Site SITECODE-Engineers, but no audit trail. Additionally:

  • Write on object Local-Core for this site

  • Write on object Site (KPI Model)

  • Write on object Site (ISA95 Model)

References are inherited to the subtree of the objects mentioned above. This configuration allows the profile to:

  • Write to variables or holder objects

  • Write to IO-Items (and their shopfloor tags). Write-able IO-Items only exist under write datasources. By standard, all datasources will be read-only datasources. Special datasource object are created, that just contain the tags that should be write-able.

SITECODE-Administrators

As SITECODE-Engineers. Additionally:

  • List / Read / Modify on object Core-Logic for this site

  • List / Read / Modify on objects of type Connector for this site

  • List / Read / Modify on objects of type Message Broker for this site

References are inherited to the subtree of the objects mentioned above. This configuration allows the profile to:

  • Create and delete any objects below the objects mentioned above (for example configure IO-Items)

  • Configure object metadata, properties and scripts in the objects mentioned above.

  • Create scripts on Security Perimeter and on SITE Connector objects

  • Disable / Enable datasources

SITECODE-Auditors

As SITECODE-Engineers.

Global Profiles

The following profiles exist for global level. They are created when a Master-Core is deployed, as per the configuration instructions:

Global-Readers

The profile does not have DataStudio access. It has the following descriptors set:

  • List / Read on Global Core object

  • List / Read on object enterprise (KPI Model)

  • List / Read on object enterprise (ISA95 Model)

References are inherited to the subtree of the objects mentioned above.

This configuration allows the profile to:

  • Read data from all sites

  • Read data from global Node-Servers

Global-Engineers

The profile has DataStudio access. Audit trail is visible. It has the following descriptors set:

  • List / Read on Global Core object

  • List / Read on object enterprise (KPI Model)

  • List / Read on object enterprise (ISA95 Model)

References are inherited to the subtree of the objects mentioned above.

Global-Writers

Like Global-Engineers. No audit trail is visible. But additionally:

  • Write on object Global Core

  • Write on object enterprise (KPI Model)

  • Write on object enterprise (ISA95 Model)

References are inherited to the subtree of the objects mentioned above.

Global-Administrators

Like Global-Engineers. But additionally:

  • List / Read / Modify on object global Core-Logic

  • List / Read / Modify on all global Connector objects

References are inherited to the subtree of the objects mentioned above. Audit trail is visible.

The above requires that the references for Global-Administrators are added when a Connector is deployed, on Site or Global level.

System-Administrators

This profile has full administrative access to all models. Audit trail is visible. With this configuration, it can perform the activities:

  • Modify access model

  • Modify all objects

  • Modify audit trail permissions

This profile is the only profile, that can configure the Access-Model, and that can enable and create components.

Global-Auditors

Like Global-Engineers.

Emergency Access

A local windows emergency user on the Master-Core can be created with administrative access, which is associated with the System-Administrators group. This is required for handling crisis situations with an Active Directory outage. In that situation, an RDP session to the Central-Core would need to be created with this local user, and DataStudio started on the Central-Core.

An emergency profile can also be used. Without an active directory, RDP access to the Central-Core server might not be possible. If network connectivity is still available, DataStudio could be running on another machine, and login with the emergency profile.