Deployment Schemas

This document considers various deployment schemas that providers along with application vendors can use to integrate the APS controller with original applications through their APS connectors.

Classification

Up to three different deployment schemas can be used concurrently in the same infrastructure to integrate the APS controller with various original applications through their APS connectors.

The first deployment schema is based on internal APS connectors installed on an HTTP host bound to both networks - the Backnet and the Internet (or FrontNet).

Two other deployment schemas are based on external APS connectors installed in the Internet, for example, in a PAAS cloud. The following are examples, when one of these two schemas is required:

• An application does not expose its native API and that is why it is better to have an APS application instance installed close to or inside the application system. This requires to have a respective APS application endpoint exposed in the Internet.
• A syndication scenario allows one OSS to use services exposed by another OSS based on Odin Automation.

Internal Connectors

APS connectors are installed on a web server connected to both, Backnet and the Internet. When an APS connector interacts with the APS controller, they authenticate each other through SSL certificates. The same schema works when using a VPN channel between the APS controller and an APS connector.

Get more details in the Internal Connector section.

External Connectors Authorized through SSL

APS connectors are available through the Internet. The APS controller must be available for the connectors through a reverse NAT. When the APS controller interacts with an APS connector, a TCP session is established between them directly. This allows them to authenticate each other through SSL certificates similar to the case with internal APS connectors.

Get more details in the External Connector with SSL Authentication section.

External Connectors Authorized through OAuth

In this case, the APS controller rely on a proxy server for REST requests in both directions - outbound and inbound. In the Internet, the APS proxy functions on behalf of the APS controller. An APS connector and the APS controller authenticate each other through the OAuth protocol.

Get more details in the External Connector with OAuth Authentication section.

Special APS Properties

Network

To inform the APS controller that an APS connector is external, a REST request for setting an APS application instance sent to the APS controller must contain the aps.network property with the “proxy” or “public” value assigned to it.

For example:

POST /aps/2/applications/

{
   "aps": {
     "network": "proxy"
   },
   ...
}

The aps.network property influences the APS-Controller-URI header that the APS controller uses in its request to an application. The property may have the following assignments:

• “network”: “public” - the APS controller must assign its public URI to the APS-Controller-URI header in the request it forwards to the application.
• “network”: “proxy” - the APS controller is aware that it must forward a request to the corresponding application through the outbound proxy as explained in the External Connector with OAuth Authentication section. In that request, the APS controller must assign its public inbound URI to the APS-Controller-URI header.

In one or another case, the APS controller must be configured as explained respectively in the External Connector with SSL Authentication and External Connector with OAuth Authentication sections.

Authentication

By default, the APS controller and an APS connector use a pair of X.509 keys to authenticate themselves. When creating an APS connector on an external system (for example, kind of PAAS), the latter may require another authentication type. Often the OAuth authentication is required.

Currently, the APS controller supports two authentication protocols, X509 and OAuth. To specify one of them, use the aps.auth section in the REST body.

X509 Authentication

X509 authentication is used by the APS controller by default. It is based on using a pair of encryption keys and certificates generated by the APS controller. The default configuration is equivalent to the use of the x509 property in the aps section as follows:

{ "aps": {
   ...
  "auth": {
    "x509": null
    }
  }
}

OAuth Authentication

OAuth ensures a ‘secure delegated connection’ between the APS controller and an APS connector by means of the shared OAuth key and secret as provided by the owner or administrator of the APS connector. Authentication through OAuth as implemented by APS is based on the 0-legged OAuth:

{ "aps": {
   ...
  "auth": {
    "oauth": {
      "key": "c4b3510e-a432-4e2c-940c-d151e05b68fg",
      "secret": "b57247b4-8174-420c-aa0f-1f7f863bb616"
    }
  }
}

The one who creates an APS connector must provide the connector with the same pair of OAuth key and secret that will be used to sign the REST requests interchanged by the APS controller and the APS connector. The APS controller will use the key to sign the REST requests it forwards to the APS connector and to decrypt the signature it finds in messages signed and sent by the APS connector.

← Interaction through APS Connectors

Internal Connector →