INTER-API Features

In addition to those features, this new version provides a unified API access to INTER-LAYER, integrates with the Identity Manager (thus whole INTER-FW) and provides fine-grained access control. It also provides full support to Pilots and Open Calls. We refer to this M30 release as INTER-API V2 in the text that follows. The release is tagged as V2 as it contains substantial advancement from the previous version as well as some changes that are not backward-compatible.

INTER-API is a deployment of the WSO2 API Manager with INTER-IoT API definitions and some extended functionalities through implementation of API mediators.

The INTER API V2 release provides the flowing features specific to INTER-IoT:

  • Deployment type. The API Manager solution can be installed either stand-alone or integrated with the INTER-FW solution (UI and Identity Server). Depending on the deployment, it offers either basic or advanced authentication and authorization features.
  • INTER-FW SSO. Integration with the INTER-FW Identity server.
  • Fine-grained access control. A specific extension (mediator) to allow the definition of custom security policies. In this way different controls can be put in place, for example "Allow user X accessing only device Y".

    We have identified the following types of API users with the corresponding set of access and management privileges: INTER-FW core users (full access to all INTER-FW features), INTER-FW front-end users (restricted set of access rights necessary to execute API calls). In addition, a set of access policies, using SAML definitions, is being developed as part of INTER-LogP specific requirements.

  • INTER-LAYER component access. It supports supports access to single INTER-LAYER components using their HTTP API "as-is" and allows basic authentication.

  • Unified INTER-LAYER access. The main feature is unified access to all INTER-LAYER components through a unified REST API endpoint (by means of a custom API mediator). The creation of a unified API access through the API manager consists of several steps:

    • Create an API design document for each INTER-LAYER component, in principle provided through Swagger definitions.
    • Analyze existing APIs and focus on REST best-practice approach and different naming conventions among INTER-Layers in order to use a unified approach.
    • Define a unified API interface, with specification of mappings to corresponding back-end systems.
    • Create a unified OpenAPI definition in addition to a "mediator" module that maps the APIs.
  • Monitoring. Out-of-the box metrics and API monitors have been activated to leverage functionalities provided by underlying WSO2 products. These include API Analytics and Carbon Metrics.

  • Dockerized deployment. The INTER-API core with all dependent modules can be deployed through a single Docker Compose script. This facilitates the deployment and takes care about correct dependencies among components. An additional compose script for the deployment of INTER-FW, Identity Server and INTER-API is provided as well to support simultaneous deployment of the whole Framework.

Extensibility

The selection of WSO2 API Manager as basis for the INTER-API provides several opportunities for customization and extension of features provided by INTER-IoT. The following list addresses those we find most relevant for addressing IoT interoperability tasks:

  • INTER-LAYER REST API evolution. Each INTER-LAYER component has several extensibility mechanisms that allow adding new functionalities or improvements of existing services. This will inevitably lead to changes in REST API calls exposed by single layers. INTER-API provides API Life-cycle Management and Versioning, so that every change is typically deployed as a prototype for early promotion. After a period of time during which the new version is used in parallel with the older versions, the prototyped API can be published and its older versions can be depreciated. With updates to OpenAPI definitions of the Unified INTER-IoT REST API every change is documented and presented to prospective users in a standard format adopted by a majority of modern software development frameworks.

  • Custom mediation sequences. The default mediation flow can be extended with the development of custom mediation sequences. In the case of the Unified INTER-IoT REST API, two Inflow Custom Mediation Extensions have been provided: (1) Integration with Identity Server SAML security policy definitions. This integration allows extension of existing security policies in the Identity Server. (2) Mediation for the mapping of unified API calls to INTER-LAYER and re-mapping of received responses.

    With further implementation of Inflow and Outflow Custom Mediation Extensions users can implement use-case specific APIs to, for example, execute a series of INTER-LAYER calls, merge the results and serve them to users.

  • Custom authorisation policies. Custom authorization policies can be defined to consider REST API segments (resources) and parameters. In this way, very fine-grained access policies can be defined. The precondition to use custom authorization is the integration with the Identity Server.

  • Integration with corporate User Stores. In INTER-IoT pilots and tests two different deployments have been used: (1) Self-standing API Manager with build-in identity management and (2) integration with the WSO2 Identity Manager. In principle, WSO2 API Manager can be integrated with several User Store types, such as LDAP, Active Directory and custom realms.

The decision to use an existing product as basis for API management has been shown as a very good choice, as it allowed us to easily adapt and extend by taking into account feedback from Pilot and Open Calls developers. It also allows implementation of extensions unforeseen by INTER-IoT requirements and use-case definitions.