OverIT APIs allow to specify which operations a client is authorised to call.
The first approach that is offered by OverIT is the configuration of allowed paths in the user type. This approach is called CRUD configuration and it allows wildcards and to specify the type of operations that are allowed to be called, for instance: CRUD /* means that any CRUD verb can be called on every published API. The CRUD authorisation feature is linked to the edit permission of the user type UI which is foundation.ux.usertype.edit.
Deep diving into the feature, the configuration possibilities are as follows:
-
First part: operation
-
Cfor Create (POST) -
Rfor Read (GET) -
Ufor Update (PATCH) -
Dfor Delete (DELETE) -
-to deny the corresponding operation -
i.e.
-Dto deny deletions
-
-
Second part: path
-
Must start with a
/character -
Defines the services (indicated by the URI of the resource) to which the first part applies
-
Supports the
*wildcard -
i.e.,
/r2/myresource
-
-
An example:
-
CRUD /r2/*allow CRUD operations on all APIs version 2 -
-D /r2/*deny DELETE operations on all APIs version 2 -
-CRUD /r1/*deny CRUD operations on all APIs version 1
-
User type privileges authorization
The second approach offered has been implemented in NextGen FSM and it is based upon functional user type privileges. The application allows system configurators to set a fine-grained collection of privileges to every user type. These privileges are detailed and based on domain entities, which allows for REST APIs to adopt them to check for authenticated user authorizations. Currently, the REST API providers need to add the proper user type privileges checks in the API operations, more specifically in the related business tasks, and the application will perform those checks. If a check is not passed, the application will throw an exception and return an error code 403 Forbidden to the client.