Security Overview
An important part of a multi-tenant system is security. Not only access to the platform is secured but information inside the platform is inexplicably linked to the owner of that data and can only be accessed by users authorized by the owner.
The security system can be broken down in two parts: Authentication and Access Control.
Authentication
Access to the platform is delegated by means of a logon which Euphoria provides to its customers. This logon gives access to the platform but also all authorized applications.
Authentication in CCP uses the Basic Authentication specification. The system is pluggable so we could expand the available methods of authentication in future versions.
Basic Authentication
Basis Authentication is a part of the HTTP standard. It's comprised of an authorization header which is added to the request. The details of the spec are found here
NOTE: It is required when using basis authentication that the header is provided in every request. Not using the header results in a HTTP 401 error (not authenticated).
HTTPS
When using basic authentication a base64 version of your username and password is transferred from the client to the server. This is inherently unsecure. That's why basic authentication is only considered secure when used in conjunction with HTTPS. CCP can only be accessed using a HTTPS connection.
RECOMMENDATION: It is a recommended practice to verify the server certificate used in the communication. This so called peer verification is an important security feature to make sure your client is communicating with a real and verified CCPService.
Access Control
When a user has a logon to access the platform, every action that user does using the api is controlled by our access control layer. The access control layer is primarily a role based system. Each account is connected to one role. The account inherits rights from the role. It is possible that individual accounts can have custom rights but generally it's all based on the roles. See the reference for a description of the different Roles.
Modules
Another layer of access control is the modules system. A module is a container which Euphoria can enable or disable for an account. Modules are used to enable specific functionality for a user. A module addition changes the rights of the user. In most scenario's specific checking of modules from a client is not needed, the entity rights should be sufficient. But for very specific scenario's it could come in handy to enable or disable functionality based on modules.
To retrieve the modules enabled for the current client user there is a function named GetUserModules available. This function returns a collection of numbers corresponding to the different modules in the system. The list contains only the modules that the user is entitled to. To retrieve the list van of all modules to link the right module to the corresponding number execute a GET request to the entityset Modules. This returns a collection of Module.
Check specific module
It's also possible to check if the user has rights to a specific module. To check if the user has access to the module with moduleid 1 execute a GET request to
/CheckUserModule?moduleId=1
This returns a Boolean value true or false.
Module Inheritance
The module system has one additional feature which should be transparent for the user. When enabling a module for a role (e.g Complaints) it should enable specific functionality not only for the account but also for owned entities by that role. This module inheritance is done automatically by the platform. The client does not need to do anything special. For instance, when developing a traveler application the entity rights of the traveler automatically reflect all rights of the traveler role and inherited from modules of the owning entity (transporter, location or contractor)