Previous topic

WizardControl

Next topic

Resource Query Language

DOCUMENTATION
Last updated 18-May-2016

Security Model

APS security model defines authentication and authorization mechanisms to protect APS objects.

Authentication

APS controller, as the service bus authority, interacts with other APS participants - application instances and users (through UI).

../../_images/security-authentication.png

These three types of actors authenticate (identify) themselves in the following way:

  1. APS controller uses own application client certificate when interacting with applications.
  2. Each application instance uses own application client certificate when interacting with the APS controller.
  3. UI, when interacting with the APS controller, authenticates the active user by means of the user or account token. The received token allows the APS controller to further identify the actor - whether it is the provider, or a reseller, or a customer, or an end-user.

Note

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.

Authorization

Once the opposite side is authenticated, the APS controller defines the operations allowed for the interacting actor. The authorization mechanism defines what operations over a resource are allowed for a certain actor. It is based on the following key points.

  • APS controller acts on behalf of the system and thus is allowed to perform any REST operation exposed by application services.

  • APS controller authorizes an application instance for any REST operations over resources provisioned from the application instance.

  • APS controller authorizes a user for REST operations over a resource depending on the following settings:

    • The user role in the account hierarchy, i.e. whether the user presents an-end user or one of accounts (provider, reseller, or customer) as described in Security Roles.
    • The user’s or account’s relation with the resource, i.e. whether the user or account is the resource owner or has another relation with it as described in Security Roles.
    • Access definition in the resource as described in Access Rights Policy.

Security Roles

APS package developer can define access rights for the following roles:

  • Resource Owner is a user or an account of the system that owns this APS resource. The role is assigned in the following cases:
    • During provisioning, the ownership is assigned by the provisioning system. If an organization subscribes to a resource, the organization (account) will be the owner of the resource. When a resource, e.g., mailbox, is created for a user, the user will be the owner of the resource.
    • When an account administrator creates a resource, the account will be the owner of the resource. When an end-user creates a resource, this user will be the owner of the resource.
  • Resource Referrer is a user or an account of the system that has an APS link (relation) to the APS resource, but does not own it. For example, if a link is created between a user and a virtual server, the user will be a referrer of the server, and the server will be a referrer of the user.
  • Administrator (account) of a resource owner is an Administrator of the resource. For example, if a customer account was created by a reseller account, the reseller is the administrator of this customer.

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:

../../_images/aps-actors.png

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:

../../_images/aps-actors-hierarchy.png

Access Rights Policy

Access rights are defined on different levels of resource Type declaration as specified in the Access Attributes section:

  • Whole Resource as described in general definition of a type
    • Owner = ALLOW|DENY (Default: ALLOW).
    • Referrer = ALLOW|DENY (Default: DENY).
  • Resource Methods as described in declaration of type Operations
    • Owner = ALLOW|DENY (Default: ALLOW).
    • Referrer = ALLOW|DENY (Default: DENY).
  • Resource Properties as described in declaration of type Properties
    • Owner = ALLOW|DENY (Default: ALLOW).
    • Referrer = ALLOW|DENY (Default: DENY).

Zimbra Example

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:

../../_images/aps-zimbra.png

Context Concept

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.

../../_images/aps-security-context-customUI.png

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.

../../_images/aps-security-context-app1.png

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.

../../_images/aps-security-context-app2.png

Due to the impersonation, the APS controller will process any REST operation requested by the application instance in the customer’s context.