User management

User roles

There are three types of user’s roles in Quobis wac:

  • admin: Used for reporting roles and management. These users will have access to all the content on the system and will not be limited by permissions and/or capabilities

  • user: for standard uses, they are limited by user/domain capabilities.

  • anonymous: intended for external users with a limited scope of time or a single session

Users on the system are organized on User domains. The domains allow to spread capabilities and provide services on a limited way to a selected group of users. Different use cases could take advantage of this concept, like different companies sharing the same instance, or maybe different offices of the same company. Every resource on the system belongs to a domain, so there is a default domain configured on the system. There is a base domain called quobis but extra domains can be created based on your use case requirements.

User IDs

Users have a unique identifier, the UUID. The UUID is defined as an unique identifier of a working element on the system. It can refer to a user, a group or to any other entity that can be referred on the system. This is used to resolve usernames, alias and any other element user-friendly to refer to a functional element. Any action in the system where users are involved needs to identify that users. On a hierarchic structure, following the URI conventions:

<resource>://<resource_id>/<subresource>/<subresource_id>

It will look for example:

wac://0/user/5732ecddd378c9b50d8f1c14

Consider it as an UID of the user. This is an internal concept to enable features like multi-tenancy, multi-domain, credentials abstraction, etc…

<username>@<domain>

The userID is unique in the system, any request to create the same username on the same domain will be rejected.

How to use the administration commands?

The administration of the Quobis wac is based on the REST API, all commands to handle the system must be done based on a REST API. You can use CURL or any other tool that allows you to consume the REST API (SAPI). We present here two alternatives:

  • CURL: to use it on bash commands via the command line interface

  • Postman: Postman is a popular API client that makes it easy for developers to create, share, test and document APIs via a graphical interface.

To run a query with CURL on a Bash script:

curl -X POST https://wac.quobis.es/wac/sapi/o/token/ \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d $'{
      "grant_type": "password",
      "username": "username@domain",
      "password": "YoUr_Pa$sWoRd"
    }'

The image below show a query using Postman, which is a quite advisable solution for day-to-day operations:

../_images/postman-doc-example.png

REST API authentication

All REST API requests must be authenticated using a Authorization header. Use the /o/token endpoint with a POST command to obtain it:

POST https://wac.quobis.es/wac/sapi/o/token/ \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -d $'{
      "grant_type": "password",
      "username": "username@domain",
      "password": "YoUr_Pa$sWoRd"
      }'

Build your authentication header with the token_type and access_token.

Authorization: <token_type> <access_token>

Both fields are provided by the WAC as response if the user is valid:

{
  "access_token": "ffda919214b7d8cfafcb2c67fc4bf27a68f6120a4dd7de2ac2ce61009",
  "refresh_token": "2947926b49285a734a577a0343d6a824c0e77d52824cfd460df89042",
  "expires_in": 3599,
  "token_type": "Bearer"
}