Skip to content

12.21 Support for configuration of and authentication to non-oneM2M node

12.21.1 Description

This use case is to provide support for authentication of oneM2M user applications to non-oneM2M vendor's specific node (server, or IoT application). The authentication is required to configure the non-oneM2M application through the user application. The objective is to ease IoT services developers to integrate with devices which their applications require to be authenticated to specific platforms. For example, it can be a camera with vendor specific cloud server which must authenticate the user or the application which configures the camera. This is important to avoid that an attacker or a non autorised person control or configure the camera.

Let assume there are 3 communication channels between user application and vendor specific platform which is non-oneM2M node:

  • communication channel for authentication,
  • communication channel for node and stream configuration/control ,
  • communication channel for data streaming. This is the classic stream used for data transport.

Those are introduced to simplify authentication and configuration of non-oneM2M platform provided by a vendor using an authentication method (standardized or proprietary). Communication channel for data streaming is out of oneM2M scope and is separated from configuration and authentication channels. The M2M System is used only for the authentication and configuration process.

This use case addresses needs of applications that require to register on non-oneM2M vendor specific applications or platforms. Please note that the camera and video streaming is given only as an example. Streamed data could be also photos, music, files, etc. Other data flows could be considered. The use case aims to highlight the need to configure and authenticate to non-oneM2M entities.

12.21.2 Source

REQ-2018-0001R05-TR-0001 use case for authentication to non-oneM2M devices.

12.21.3 Actors

Vendor specific node (application or server), AE (user application).

12.21.4 Pre-conditions

None

12.21.5 Triggers

  • User Application wants to authenticate to non-oneM2M specific vendor node (authentication communication channel).
  • User Application wants to change configuration of non-oneM2M specific vendor node or data streaming provided by this node (configuration/control communication channel).
  • User Application wants non-oneM2M node to start streaming data (configuration/control communication channel).
  • User Application wants non-oneM2M platform to stop streaming data (configuration/control communication channel).

12.21.6 Normal Flow

  • Application entity wants to authenticate to non-oneM2M platform. To do so the user application (AE) sends the authentication request through the IoT Server (MN/IN-CSE) and Proxy-API using authentication communication channel. Proxy-API translates given request and forwards it to non-oneM2M platform. Then it responds using the same dataflow channel. This process is depicted in step 1 of Figure 12.21.9-1.
  • Application entity wants to change configuration of non-oneM2M node or data stream. To do so AE sends the configuration change request through IoT Server (MN/IN-CSE) and Proxy-API using configuration communication channel. Proxy-API translates given request and forwards it to non-oneM2M node (device or platform). Then it responds using the same communication channel. This process is depicted in step 2 of Figure 12.21.9-1
  • Application entity wants to control data streaming provided by non-oneM2M node (device or platform). To do so AE sends the control request through IoT Server (MN/IN-CSE) and Proxy-API using configuration/control communication channel. Proxy-API translates given request and forwards it to non-oneM2M platform. If it is needed it responds using the same communication channel. This process is also depicted in steps 2 of Figure 12.21.9-1 (same flow with configuration flow).

12.21.7 Alternative Flow

None

12.21.8 Post-conditions

None

12.21.9 High Level Illustration

Figure 12.21.9-1 depicts high level illustration of describing use case. Data streaming communication channel is out of one-M2M scope and is separated from authentication and non-oneM2M node configuration/control communication channels. According to Figure 12.21.9-1, it's possible for the Data streaming to be received by another user application(s).

Figure 12.21.9-1 Call flow for configuration and authentication

Figure 12.21.9-1 Call flow for configuration and authentication

12.21.10 Potential Requirements

  • The M2M System must be able to distinguish between the raw dataflow and the configuration/control flow for the purpose of authentication.
  • The M2M System must be able to provide an framework for end-to-end authentication of user application to the M2M vendor's specific node (non oneM2M).