Adding a basic HTTPS connection

Basic HTTPS connections, also known as NS-AS Tunnel Interface, provide a direct bidirectional connection between the Network Server (NS, also known as LRC in ThingPark architecture) and third-party Application Servers (AS) using HTTPS protocol.

For security purposes, downlink messages are accepted only if an encrypted token is included in the POST. Device payloads are exchanged in an encoded format without the support of payload drivers.

This connection type does not support message queuing services: when the AS is temporarily unavailable or overloaded, the uplink messages will be lost. The AS may also be temporarily blacklisted if it becomes unreachable or cannot respond in a timely manner.

To learn more about basic HTTPS connections and NS-AS Tunnel Interface, see the Tunnel Interface data-plane API.

---

1. Select Connections, and click ADD CONNECTION on the Connections page, or from Dashboard, go to the CONNECTIONS widget, and click.

2. Click the Basic HTTPS type of connection.

3. Enter your connection information (mandatory fields are marked by * in the user interface):

   • Name

   • Domains (optional): If the permission segregation based on domains has been enabled by an administrator user, you may associate your connection with domains to restrict its visibility. Domain-specific connections are visible only to authorized users whose domain restrictions match. To learn more, see About domains.

     • If no domains are set, the connection is cross-domain and visible to all users. However, users having domain restrictions have read-only access to cross-domain connections and cannot see any confidential information such as the URL and the custom headers.
     • If your user account has domain restrictions, the associated domains must match your domain restrictions without any domain prefix (only full domains can be assigned to resources).

   • Additional information (optional): Any useful information, administrative for instance, that is related to the connection.

4. Configure the tunnel interface authentication:

   • In the Key area, click to save the auto-generated key that you must share with the HTTPS application server.

     info

     This system-generated security key provides an application-level signature to the uplink messages sent from ThingPark to the application server (AS), as well as the downlink messages sent from the AS to ThingPark. This is needed for uplink path, to ensure that the UL report was generated by ThingPark; and for downlink path, to ensure that only an AS having this key can send downlink messages to your devices.

     To learn more about the use of this key, see Tunnel Interface authentication.

   • Maximum timestamp deviation (optional): To enhance security against replay attacks, enter the tolerance of the downlink timestamp deviation, expressed in seconds.

5. Configure the destinations:

   • URLs: Enter the URL or URLs of the application server where ThingPark will send uplink messages. Note: URLs are processed in the order they are listed. The URL format must follow RFC-3986.

   • Strategy: Only applies if several URLs are declared in URLs.

     • Sequential: Attempts the routing in the defined order of the URLs and stops routing to the following URLs once a 2xx response (successful) is received from the last attempted URL. Maximum 5 URLs.

     • Blast: Always route to all the URLs in the defined order. Maximum 3 URLs.

     advanced

     If you want to segregate routing of uplink packets according to the LoRaWAN frame port, you need to define multiple routes:

     1. Click ENABLE PORT-BASED ROUTING.

     2. Configure Port(s), URLs, and Strategy for each route you add, while respecting the following rules:

        • You may define one or more eligible ports as a comma-separated list (for instance 1,5), or a range (for instance 1-5).

        • Use only * for the last route to wildcard all the remaining ports.

        • A given port cannot be set on different routes.

        • Uplink messages without LoRaWAN payloads are always sent to the first route only.

     Tip Use the to reorder your routes as needed.

     Note Creating only one route is like not enabling port-based routing.

6. Configure the HTTP requests:

   • Custom HTTP Headers (optional): To meet the application server's needs, you can define up to 5 custom HTTP headers in uplink messages for each basic HTTP connection. Each custom HTTP header is statically defined as a string (for instance, "Authorization: Bearer AbCdEf123456").

     • In Custom HTTP Headers, click +.
     • Each header is composed of two fields to be defined following RFC 7230:
       • Header Name: "Accept", "Host", "User-Agent", "Content-Length", "Content-Type", "Expect" and "Proxy-Authorization" are forbidden. A given header name can be configured only once (case insensitive).
       • Header Value
       • The maximum length of an HTTP header (name + value) is 510 characters.
     info

     You can define explicitly the "Authorization" header as a custom HTTP header, but it can also be implicitly generated by the network server when the destination URL contains a login/password (for instance, http://user:pwd@application.com). When both are defined, priority is given to the login/password defined in URLs in Configure the destinations (step 5).

   • Content Type: The type of encoding used to report device data to your application. Use the same content type as the application server:

     • XML

     • JSON. Example:

       {
         "DevEUI":"78A8952D2E2992C5",
         "FPort":2,
         "LrrRSSI":-60.000000
       }

     • JSON untyped: JSON document where all values, including numeric values, are reported as strings. Example:

       {
        "DevEUI":"78A8952D2E2992C5",
        "FPort":"2",
         "LrrRSSI":"-60.000000"
       }

7. Click ADD.