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.
In this document:
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 of 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 having a respective APS application endpoint exposed in the Internet.
A syndication scenario allows one OSS to use services exposed by another OSS based on CloudBlue.
APS connectors are installed on a web server connected to both the 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 Connectors section.
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 Connectors with SSL Authentication section.
In this case, the APS controller relies 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 Connectors with OAuth Authentication section.
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 Connectors with OAuth Authentication section.
In that request, the APS controller must assign its public inbound URI
to the APS-Controller-URI
header.
In either case, the APS controller must be configured as explained respectively in the External Connectors with SSL Authentication and External Connectors with OAuth Authentication sections.
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, in a 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 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 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"
}
}
}
When installing an APS connector, you 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.