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:
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.