APS controller, as the service bus authority, interacts with other APS participants - application instances and users (through UI).
These three types of actors authenticate (identify) themselves in the following way:
A token is generated for an account (staff member) or end user for a limited period of time. An application certificate is generated by the APS controller and passed to the application instance during application provisioning.
APS package developer can define access rights for the following roles:
Resource Administrator role always has full access to the APS Resource. For the others, the access is defined in the APS package as presented in the following diagram:
In a hosting system, these rules usually work recursively: i.e. the administrator of administrator also has full access to the resources below in the hierarchy:
Access rights are defined on different levels of resource Type declaration as specified in the Access Attributes section:
An example of the services hierarchy of the Zimbra application and required access rights associated with them is shown in the diagram below where sp represents the service provider:
Security Context in APS is a zone of resources visibility for an account or end user. It means, each of accounts (provider, reseller, or customer) and end users will have own context. The context of an account or user contains all resources that the account or user owns. Once the APS controller authenticates a user, it allows the user to work with resources in their context. In the following example, a user is authenticated with a customer’s token and thus has access to the customer’s context as a staff member.
An application has full access to all resources provisioned from it. In the following example, the application App1 is authenticated through its certificate and thus gets full access to all resources provisioned from the application.
In some cases, an application may need to manage resources from another application. For example, to provision a resource for a customer or user, an application needs to reserve storage or modify a mailbox provided by another application in the same customer’s (user’s) context. APS controller enables an application for such operations by means of the impersonation mechanism.
Impersonation allows an application instance to get full control over an account’s or user’s context. Therefore, in its REST CRUD request, the application instance needs to fill a special field, APS-Resource-ID, in the HTTP header with the ID of a resource provisioned from this application instance and visible in the customer’s (user’s) context. In the following example, the application instance App2 impersonates itself through Resource-N provisioned from the application instance in the customer’s context.
Due to the impersonation, the APS controller will process any REST operation requested by the application instance in the customer’s context.