История страницы
"Access Control" is one of the modules included in the ROBIN platform, designed to manage users of the platform and customize their access rights to modules and objects (robots, machines, etc.) of the system. The module is available only to users with the "Access Rights Administrator" role.
You can restrict access to:
- Platform modules and applications:
- "Access Control" module
- "Orchestrator" module
- Robin Process application
- ROBIN Studio Enterprise application
- ROBIN Player Enterprise application
- Objects added to the platform's remote storage:
- robot projects (the user publishes them to the repository himself via ROBIN Studio)
finished robots (the user publishes them to the repository via ROBIN Studio).
machines accounts - server or personal computer (the ROBIN Agent automatically transfers the machine data to the repository as soon as the client part of the platform is installed on the machine).
- processes
robot start schedules (added to the storage when the user creates them via the Orchestrator module interface).
Users access rights to components and objects are delimited by tenants.
Tenants are some kind of multigroups, each of which has its own sets of objects, object groups, users and roles.
Each tenant has its own settings, access rights, and other aspects of process management. This provides data isolation and access control between different groups of users or projects.
When entering the web-interface of the platform or its desktop application, it is necessary to select the tennant within which the work will be performed. The selected tennant will depend on:
- Which objects are available to the user. The user always sees only those objects that are added to the tenant under which he/she has logged in.
- What operations the user can perform on the objects. The available operations are determined by the role(s) the user has in the selected tenant.
- The accessibility of the component itself. Access to the component is also determined by the user's role. If the user does not have a role in the tenant that allows the user to work with the component, it will be hidden (web interface) or the system as a whole will deny access (desktop applications).
To access A user cannot log in without a tenant, so the user must have access to at least one tenant to work with modules and applications. To gain access to a tenant, a user must be added to it, and necessarily with one or more roles created in that tenant. A user can be added to several tenants at once. The user can have different roles in each tenant. But even with access to several tenants, a user can log in to the system only within one tenant. When deploying the platform, a single tenant is always created, which can be used to start working with the platform.
Also within a single tenant, you can more accurately differentiate user access to tenant objects by grouping them. The principles of grouping are as follows:
...
By default, groups do not exist in tenant, they must be created separately (if necessary).
Limitations of the current release.
...
Ограничения релиза
На данный момент не реализованы некоторые вышеперечисленные функциональные возможности:
...
.