User and group identification is tightly related to security although Plastic SCM handles it as different layers: on one hand the permissions to set to objects and assigned to certain "user identifiers" and by the other hand the users and groups where the "user and group ids" come from.
This way "user identification" is achieved using one of the following mechanisms:
Users and groups are retrieved from an existing LDAP or Active Directory.
It can be seamlessly configured to work on Windows, Linux and macOS.
The Plastic SCM server will handle users and groups with a file based mechanism (users.conf and groups.conf files). This alternative is very useful for departments who can't rely on the corporate security setup, small teams and also for distributed developers working disconnected from the main site.
Designed with testing and evaluation in mind the "name" modes rely on the user and group names existing on both the client and server. If the names match then the user is correctly identified. This mechanism is not secure unless the underlying network is totally secured and hence it is not recommended for production.
Each repository, branch, label, attribute, trigger and even server can have an associated ACL in Plastic SCM.
Each ACL can have several entries, each of them associating to a user or group a set of granted or denied permissions.
The following picture illustrates how an ACL associated to the "main" branch looks like based on the previous definition:
There are certain permissions that can be applied to the server to control certain operations:
Permissions that can apply to several objects inside the repository.
While this permissions are applied to branches, they control whether specific file and directory operations can be applied.
These permissions were introduced in Plastic SCM 4.2.
They can also be applied to an special secured object called "secured path" which means users can define rules such as: "never let coders checkin under the /art/photoshop directory".
The list of permissions is:
They are useful to control replication operations:
Permissions in Plastic SCM are inherited from the top object in the hierarchy (the server) down to the lower ones.
This way it is very simple to set a permission at the server level that will apply to all repositories or at the repo level for all branches and so on.
Permissions can be set from the GUI or from the CLI using the cm acl command.