Permissions - STARIONGROUP/COMET-SDK-Community-Edition GitHub Wiki

CDP4-COMET makes use of a Role Based Access Control that is based on the ECSS-E-TM-10-25A-Annex-A. ECSS-E-TM-10-25A-Annex-A contains concepts such as roles and permissions. The permissions scheme of ECSS-E-TM-10-25A-Annex-A is very flexible and fine-grained providing the advantage of being very configurable; the disadvantage is that an expert on the Data Model is required to make sure no mistakes are made due to which access is restricted to certain data that is required to succesfuly perform Concurrent Design.

Two kinds of roles can be defined: a PersonRole and ParticipantRole. Both kinds of roles contain so-called permissions that determine what that role is allowed to do. These two roles are in line with the data partitioning that exists in the COMET-Data-Model and the containment structures along the SiteDirectory and EngineeringModel.

A PersonRole can be assigned to a Person and is used to determine what a Person is allowed to do in the context of the SiteDirectory

The Person class represents a user in COMET.

The PersonPermission class is used to capture the access that a PersonRole will give a Person. The PersonPermission combines a PersonAccessRightKind and ClassKind. The Classkind is an enumeration datatype that denotes all the possible classes in the COMET-Data-Model. The PersonAccessRightKind is an enumeration datatype that defines the possible access rights that are applicable for a class. By making a combination of these two enumerations it is possible to state what kind of permission a user has for that datatype.

The following PersonAccessRightKind enumeration literals exist:

*1] => Exception to this rule is when MODIFY IF PARTICIPANT is set for the EngineeringModelSetup itself. From version SDK 24.2.0 on, in that case an authenticated user can also create a new EngineeringModelSetup, even when the authenticated user is not a Participant of any EngineeringModelSetup. This can be checked using a specific method in the CDP4Dal.PermissionService: CanCreateOverride() as an extra step besides a normal CanWrite() check.

    ...
      this.PermissionService.CanWrite(ClassKind.EngineeringModelSetup, this.SiteDirectoryObject)
      ||    
      this.PermissionService.CanCreateOverride(ClassKind.EngineeringModelSetup, ClassKind.SiteDirectory);
    ...

Each class in the COMET-Data-Model has so called default access rights defined for the PersonPermission. In the COMET-SDK this translates to a constant that is defined for that class.

public sealed partial class DerivedUnit : MeasurementUnit
{
    /// <summary>
    /// Representation of the default value for the accessRight property of a PersonPermission for the affected class
    /// </summary>
    public new const PersonAccessRightKind DefaultPersonAccess = PersonAccessRightKind.SAME_AS_SUPERCLASS;
}

When a new PersonRole is defined, the user he user shall define PersonPermissions for all ClassKinds that have a defaultPersonAccess equal to PersonAccessRightKind.NONE. For all ClassKinds that have a defaultPersonAccess not equal to PersonAccessRightKind.NONE, a PersonPermission with accessRight equal to defaultPersonAccess for that ClassKind shall be defined.

PersonAccessRightKind.MODIFY implies read, create and update actions, and if delete is allowed, deleted actions as well. PersonAccessRightKind.MODIFY access to an object also implies the right to modify the container collection that contains the object, even if the access right to the container collection object is limited to PersonAccessRightKind.READ.

A couple of PersonPermission examples:

// Read access is provided to the SiteDirectory.
var personPermission = new PersonPermission();
personPermission.ObjectClass = ClassKind.SiteDirectory;
personPermission.AccessRight = PersonAccessRightKind.READ;

// A user is allowed to change the details of the Person object that represents him as a user in COMET. Even though this user has read-only access to the SiteDirectory
var personPermission = new PersonPermission();
personPermission.ObjectClass = ClassKind.Person;
personPermission.AccessRight = PersonAccessRightKind. MODIFY_OWN_PERSON;

// Read access is provided to the DomainOfExpertise because the user has read access to the container SiteDirectory.
var personPermission = new PersonPermission();
personPermission.ObjectClass = ClassKind.DomainOfExpertise;
personPermission.AccessRight = PersonAccessRightKind.SAME_AS_CONTAINER;

These examples illustrate that it is possible to setup find-grained permissions using this setup. But, it is also possible to create a Role that is useless in practice. The DomainOfExpertise class is a fundamental concept in the Concurrent Design methodology. It is used to express ownership of for instance design elements (Element Definitions and Element Usages) and parameters. If a user does not have at least the permission to read the domains of expertise, it would be impossible for this user to use CDP4-COMET at all.

When a permission for a datatype is set, this means that this permission is valid for all the instances of that datatype. By providing READ access to the Alias class, all Alias instances can be read by this role, unless the permissons of container objects overrule this.

A ParticipantRole can be assigned to a Participant and is used to determine what a Participant is allowed to do in the context of an EngineeringModel.

The ParticipantPermission class is used to capture the access that a ParticipantRole will give a Participant of an EngineeringModel. The ParticipantPermission combines a ParticipantAccessRightKind and ClassKind. The Classkind is an enumeration datatype that denotes all the possible classes in the COMET-Data-Model. The ParticipantAccessRightKind is an enumeration datatype that defines the possible access rights that are applicable for a class. By making a combination of these two enumerations it is possible to state what kind of permission a participant has for that datatype.

The following ParticipantAccessRightKind enumeration literals exist:

ParticipantAccessRightKind.MODIFY implies read, create and update actions, and if delete is allowed, deleted actions as well. ParticipantAccessRightKind.MODIFY access to an object also implies the right to modify the container collection that contains the object, even if the access right to the container collection object is limited to ParticipantAccessRightKind.READ.

Each class in the COMET-Data-Model has so called default access rights defined for the ParticipantPermission. In the COMET-SDK this translates to a constant that is defined for that class.

public sealed partial class DerivedUnit : MeasurementUnit
{
    /// <summary>
    /// Representation of the default value for the accessRight property of a PersonPermission for the affected class
    /// </summary>
    public new const ParticipantAccessRightKind DefaultParticipantAccess = ParticipantAccessRightKind.SAME_AS_SUPERCLASS;
}

When a new ParticipantRole is defined, the user he user shall ParticipantPermissions for all ClassKinds that have a defaultPersonAccess equal to ParticipantAccessRightKind.NONE. For all ClassKinds that have a defaultParticipantAccess not equal to ParticipantAccessRightKind.NONE, a ParticipantPermission with accessRight equal to defaultParticipantAccess for that ClassKind shall be defined.

A couple of ParticipantPermission examples:

// modify access to owned ElementDefinition objects, non-owned ElementDefinition objects can be read
var participantPermission = new ParticipantPermission();
participantPermission.ObjectClass = ClassKind.ElementDefinition;
participantPermission.AccessRight = ParticipantAccessRightKind.MODIFY_IF_OWNER;

// A user is allowed to read the ExternalIdentifierMap objects
var personPermission = new ParticipantPermission();
participantPermission.ObjectClass = ClassKind.ExternalIdentifierMap;
participantPermission.AccessRight = ParticipantAccessRightKind.READ;

ECSS-E-TM-10-25A-Annex-A supports datatype based roles and permissions, but has no support for instance level persmissions. The CDP4-COMET Data Model extends the ECSS-E-TM-10-25A-Annex-A authorization system with instance level permissions. The abstract super class Thing, from which all classes derive has 2 extra properties:

1. ExcludedDomain: the list of DomainOfExpertise that should not be allowed to READ or MODIFY the Thing
2. ExcludedPerson: the list of Person that should not be allowed to READ or MODIFY the Thing

The instance level permissions are based on an opt-out mechanism. Those DomainsOfExpertise and or Persons that should be restricted from are recorded and added to the Exclude property. When a DomainOfExpertise or Person is excluded from a Thing this also implies the containment tree.

« CDP4Common-CE Meta Data  —  Documentation overview  —  CDP4Common-CE Sentinel Things »