Managing users

We are going the cover this section the basic actions to handle the users: create, list, modify and delete. All these actions here can be complemented with other actions available on the REST API.

Adding users

User are created using the Kitter service via its REST API, which will act as a broker between Keycloak (which stores the login information) and wac-core (which stores the business logic).

Editing users

As administrator, you need to update users, change its domain, or its personal data (mail, phone, etc). This can be done also by using the Kitter REST API.

Delete users

This can be done also by using the Kitter REST API.

This action will simply remove the user entry on the system. In addition, if the SIP mapping service is being used, the SIP mapping associated to that user is removed and the sip mappings pool is marked as “available”, as explained in the SIP mappings section.

Warning

All other elements linked to this user, like credentials or any other element on the database not detailed above, will not be removed with this command.

Adding SIP network access (SIP mapping)

In order to grant a user or usergroup to reach the SIP network, it is required to configure properly the SIP trunk and to add a sip-mapping to the resource. To do it, add the username of the resource on the SIP network. This will be used to identify the user or usergroup on the SIP network:

POST https://wac:8001/sapi/sipMappings/ HTTP/1.1
     Authorization: Bearer ec3fe973ea04739e1...12ec5adc8b323c83c0
     Content-Type: application/json

     {
     "ownerUri": "wac-user:aliceId",
        "credential": {
           "username": "205"
           "password": ""
        }
     }

The previous example will create a sip-mapping that will identify the user as “205” on the SIP network. Also, any call received on the SIP side with 205 as destination will be routed to the corresponding user (identified by its UUID wac-user:aliceId).

Auto-provision of users

In some scenarios, the users already exists in another system (typically, an Active Directory server) and they are not pre-provisioned on the Quobis communication platform. In this scenario, the platform can be configured in a way that any user that is authenticated in a trusted third-party system will automaticall have an account in the platform. In other words, user in Quobis wac are automatically created when a valid user, coming from a trusted third-party system, tries to log in for the first time.

Warning

In this case, the Kitter service is not involved and all the activation is done in the wac-core service and Keycloak.

When a user, that has no account in wac-core, tries to log in for the first time, the wac-core service reads it JWT and checks whether this users exists or not in the local database (by reading the username or email value according to the mapping configuration in the auth.userIdentifier parameter in config/auth.toml wac-core file).

If the user does not exist, and the auth.createOIDCUser is set to “true”, the following information will be used to create a new user in wac-core by reading this information from the JWT and the auth.toml configuration:

  • username: read from the JWT data, “username” value

  • domain: when auth.createOIDCUserForcedDomain is set, this value is used. Otherwise, this value is read from the “domain” property of the JWT

  • mobilePhone: hardcoded to a empty string

  • email: read from the JWT data, “email” value

  • capabilities: taken from auth.OIDCUserCapabilities value in auth.toml

  • role: set by defaul to “user”

  • displayName: read from the JWT data, “name” value. Keycloak generates this value by concatenating name & surname.