APS security model includes various mechanisms to protect APS applications, resources, and the platform as a whole.
APS controller, as the APS bus authority, interacts through the secure HTTPS protocol with other APS participants (actors) on the APS bus using a secure authentication of every actor.
There are the following interactions on the bus:
Platform built-in and custom UI scripts can send REST requests to the APS controller and receive notifications sent from the APS controller on behalf of APS applications. The respective sessions are set up on behalf of the user who is interacting with the platform control panel (CP) at the moment. The CP authenticates users when they log in. This makes all subsequent REST requests sent from the UI to the APS controller authenticated through the platform built-in internal mechanism.
The APS controller can send a REST request to an APS application instance using one of authentication protocols:
When forwarding a request from an actor to an APS application instance, the APS controller adds the APS-Actor-ID header to specify the actor.
An APS application instance can send its own REST request to the APS controller. The authentication goes through the method that was used initially by the APS controller (see the previous item), either SSL or OAuth.
The provider can allow a 3rd party actor (an external management system, a custom script, or a GUI REST client) to interact with the platform services through the APS controller as explained in Using Platform Services. An actor must authenticate itself by the OAuth protocol using a shared pair of a key and secret as explained in Using APS REST API.
While the authorization makes some resources, methods, and properties available to certain actors, it is also possible to hide values of some properties from human eyes without prohibiting the use of them. This typically concerns passwords, security keys, and other sensitive properties.
For this purpose, APS provides the encrypted attribute that you can assign to a confidential property.