Differenze tra le versioni di "AdminGuide:BasicConcepts:Users and roles"
(Creata pagina con "en:AdminGuide:BasicConcepts:Users and roles <div class="noautonum" style="float: right">__TOC__</div> = Users = Access to KalliopePBX GUI (as well as CTI services, LDAP...") |
|||
Riga 9: | Riga 9: | ||
Each user has one or more associated access permissions among GUI, CTI and API. | Each user has one or more associated access permissions among GUI, CTI and API. | ||
* '''GUI''': GUI access means that the user can login to the KalliopePBX web interface; GUI access also grants the user the permission to access the integrated LDAP server. | * '''GUI''': GUI access means that the user can login to the KalliopePBX web interface; GUI access also grants the user the permission to access the integrated LDAP server. | ||
* '''CTI''': CTI access allows the users to use Kalliope softwares (CTI, Logger, Supervisor Panel) which connects to the | * '''CTI''': CTI access allows the users to use Kalliope softwares (CTI, Logger, Supervisor Panel) which connects to the PBX using the CTI socket and protocol | ||
* '''API''': API access allows the users to invoke the KalliopePBX REST APIs available at http[s]://<PBX IP>/rest/ (see [[AdminGuide:REST API|REST API]]) | |||
== Builtin users == | == Builtin users == | ||
Riga 29: | Riga 29: | ||
! privacyadmin | ! privacyadmin | ||
| style="text-align:center;" | GUI (-)<br />API (-) | | style="text-align:center;" | GUI (-)<br />API (-) | ||
| this | | this user has full access to the external telephone numbers of the CDR, and is the only one who can configure call recording authorizations. It can also access call recording records, download and listen the recorded calls, as well as grant other users with the "privacy" permission, which permits the target user to have access to full numbers in CDR and to recorded calls list panel (and files). | ||
|- | |- | ||
! phonebook | ! phonebook | ||
Riga 36: | Riga 36: | ||
|- | |- | ||
! click2call | ! click2call | ||
| style="text-align:center;" | | | style="text-align:center;" | CTI (+) | ||
| | | this user may only have API access, and is useful to have third party applications to send click-to-call commands to KalliopePBX using a single privilege-limited authentication user | ||
|} | |} | ||
=== Multitenant === | |||
During Multitenant license activation the PBX and (default) tenant entities, which were bundled under a single administration entity, are separated and a new builtin user '''pbxadmin''' is created (with factory password "admin"). | |||
Management of the PBX as a system is granted to this new "pbxadmin" user, which has bot GUI and CTI permissions, whereas telephony services configuration of the tenant remains to the "admin" user. Since multiple tenants can be created, each with its own "admin" user, it is necessary to extend the authentication username to specify the relevant tenant domain. The predefined existing tenant domain is "default", so the predefined builtin users become admin@default, privacyadmin@default, ... | |||
For each new tenant which gets created (e.g. with domain "sampledomain"), a number of new users are generated, namely admin@sampledomain, privacyadmin@sampledomain, phonebook@sampledomain, and so on. | |||
Users admin@default and admin@sampledomain are completely independent and each one can only manage its own tenant. | |||
NOTE: if a user does not specify the domain when logging in (e.g. uses "admin" instead of "admin@somedomain"), then it is assumed to belong to the default domain and authentication is performed accordingly. | |||
== Custom users == | == Custom users == |
Versione delle 10:52, 10 feb 2017
Users
Access to KalliopePBX GUI (as well as CTI services, LDAP phonebook, etc.) is granted to Users. There are two kind of users: builtin and custom users. Builtin users include administrative and service users, whose role are usually predefined and not modifiable, whereas custom users are additional users that can be created and assigned to custom roles.
Each user has one or more associated access permissions among GUI, CTI and API.
- GUI: GUI access means that the user can login to the KalliopePBX web interface; GUI access also grants the user the permission to access the integrated LDAP server.
- CTI: CTI access allows the users to use Kalliope softwares (CTI, Logger, Supervisor Panel) which connects to the PBX using the CTI socket and protocol
- API: API access allows the users to invoke the KalliopePBX REST APIs available at http[s]://<PBX IP>/rest/ (see REST API)
Builtin users
The first example of builtin user is "admin" (whose factory password is "admin"), which is used to access the GUI after first firmware installation. This is the primary technical figure, and is commonly used to perform all the system configuration. Additional users may have the rights to perform configuration tasks, but they can be limited to specific GUI panels only, according to their granted Role.
The list of builtin users follows, along with their access permissions (Note: (+) means that this access permission is assigned and cannot be revoked; (-) means that the permission can be granted or not):
Username | Access permissions | Notes |
---|---|---|
admin | GUI (+) CTI (+) API (+) |
this is the main technical user. It has all the privileges on the configuration of the PBX, in terms of system (network, network services) and telephony (entites, services, etc.). It has full access to logs and registers, but it has some limitations regarding the aspects related to the privacy of the users. Firstly, it cannot see the full external telephone numbers in the CDR, but it has the last three digits masked by "xxx"; secondly, "admin" user does not have access to Call Recording configuration and files, which is limited to "privacyadmin" user (and delegated users). |
privacyadmin | GUI (-) API (-) |
this user has full access to the external telephone numbers of the CDR, and is the only one who can configure call recording authorizations. It can also access call recording records, download and listen the recorded calls, as well as grant other users with the "privacy" permission, which permits the target user to have access to full numbers in CDR and to recorded calls list panel (and files). |
phonebook | GUI (-) API (-) |
this user has read access to the KalliopePBX phonebook. It has to be explicitly enabled from the "System Settings"->"Users Management" panel, assigning it a password and the related access permissions. NOTE: GUI permission also grants the right to access the integrated LDAP server, where the KalliopePBX phonebook is published (according to the settings in "Phonebook"->"LDAP Settings" panel). The "phonebook" user is mainly useful to have a single identity (configurable through provisioning) used by the telephones to access the KalliopePBX phonebook using LDAP. |
click2call | CTI (+) | this user may only have API access, and is useful to have third party applications to send click-to-call commands to KalliopePBX using a single privilege-limited authentication user |
Multitenant
During Multitenant license activation the PBX and (default) tenant entities, which were bundled under a single administration entity, are separated and a new builtin user pbxadmin is created (with factory password "admin").
Management of the PBX as a system is granted to this new "pbxadmin" user, which has bot GUI and CTI permissions, whereas telephony services configuration of the tenant remains to the "admin" user. Since multiple tenants can be created, each with its own "admin" user, it is necessary to extend the authentication username to specify the relevant tenant domain. The predefined existing tenant domain is "default", so the predefined builtin users become admin@default, privacyadmin@default, ...
For each new tenant which gets created (e.g. with domain "sampledomain"), a number of new users are generated, namely admin@sampledomain, privacyadmin@sampledomain, phonebook@sampledomain, and so on.
Users admin@default and admin@sampledomain are completely independent and each one can only manage its own tenant.
NOTE: if a user does not specify the domain when logging in (e.g. uses "admin" instead of "admin@somedomain"), then it is assumed to belong to the default domain and authentication is performed accordingly.