Using IoT Agent JSON with HTTP transport protocol - fiware

I want to use IoT Agent JSON (https://github.com/telefonicaid/iotagent-json) with HTTP transport protocol instead of MQTT. Is it possible? How can I do it?
Thanks!

Yes, you cand o it, just follow the new github README secion where HTTP transport option is explained.
Cheers,

You only need a contiguration/template for all your devices. Such a configuration must specify the protocol is IoTA-JSON and the transport is HTTP. The request is sent to the nothbound interface of the Json IoT agent:
POST http://iota_host:iota_port/iot/services
Fiware-Service: <service>
Fiware-ServicePath: <subservice>
{
"services": [
{
"entity_type": "<default_entity_type>",
"protocol": "IoTA-JSON",
"transport": "HTTP",
"apikey": "<api_key>",
"attributes": [ "<common_active_attrs_if_any>" ],
"lazy": [ <common_lazy_attrs_if_any> ],
"commands": [ <common_commands_if_any> ],
"static_attributes": [ <common_static_attrs_if_any> ]
}
]
}
After that, you will be able to provision Json-based devices using Http transport:
POST http://iota_host:iota_port/iot/devices
Fiware-Service: <service>
Fiware-ServicePath: <subservice>
{
"devices": [
{
"device_id": "<device_id>",
"entity_name": "<entity_name>",
"entity_type": "<alternative_entity_type>",
"attributes": [ <additional_active_attrs_if_any> ],
"lazy": [ <additional_lazy_attrs_if_any> ],
"commands": [ <additional_commands_if_any> ],
"static_attributes": [ <additional_static_attrs_if_any> ]
}
]
}
Even, you could create a configuration/template without specifying the transport, i.e. the configuration/template will only relate to all the Json-based agents, independently of their transport, and then when provisioning a Json-based device, specify the transport.

Related

Openshift Open ID Identity Provider with lookup mapping method

I'm using an OpenIDIdentityProvider with mappingMethod: claim to authenticate admin users in the Openshift admin console. I'm using the auth0 service to authenticate users. The admin users are defined in an ansible playbook on deployment, effectively making the admin users hard-coded.
Is it possible to completely manage all admin and developer users using the OpenIDIdentityProvider, a lookup mapping method and adding something like extraScopes: [roles] to pull through the additional authorization roles into the authentication request? That would enable me to completely manage users and roles separately from the ansible playbook. Next level bonus points for managing permissions on the authentication provider side.
The Openshift documentation is very light on details for authentication / authorization outside of the default mappingMethod: claim.
Below is my identity provider json file for the claim-based mapping method:
{
"items": [
{
"name": "auth0",
"challenge": false,
"login": true,
"mappingMethod": "claim",
"kind": "OpenIDIdentityProvider",
"clientID": "supersecretsauce",
"clientSecret": "extrasupersecretsauce",
"extraScopes": ["email", "profile"],
"claims": {
"id": [
"email"
],
"preferredUsername": [
"email"
],
"name": [
"name"
],
"email": [
"email"
]
},
"urls": {
"authorize": "https://fancypants.auth0.com/authorize",
"token": "https://fancypants.auth0.com/oauth/token",
"userInfo": "https://fancypants.auth0.com/userinfo"
}
}
]
}
To my simple mind the below would suffice for a working lookup-based mapping method with roles returned by the authentication provider:
{
"items": [
{
"name": "auth0",
"challenge": false,
"login": true,
"mappingMethod": "lookup",
"kind": "OpenIDIdentityProvider",
"clientID": "supersecretsauce",
"clientSecret": "extrasupersecretsauce",
"extraScopes": ["email", "profile", "roles"],
"claims": {
"id": [
"email"
],
"preferredUsername": [
"email"
],
"name": [
"name"
],
"email": [
"email"
],
"role": [
"roles"
]
},
"urls": {
"authorize": "https://fancypants.auth0.com/authorize",
"token": "https://fancypants.auth0.com/oauth/token",
"userInfo": "https://fancypants.auth0.com/userinfo"
}
}
]
}
An example of a functional role value would be cluster-admin.
OpenID can only be used for authentication. You are attempting to use it for both authentication and authorization. This is not possible as roles and bindings are managed by Openshift - they cannot be delegated to an external service.

Fiware IoTAgent and Context Broker

I'm following this example to create a simple scenario where I register a new device into the IoT Agent and it forwards it to the Context Broker. Then I want to check if the created device exists in the Context Broker, and I can seem to find it.
These are the steps I'm doing:
1. using Postman I'm sending a post request to the IoT Agent:
url: http://eidas5.lab.fi-ware.org:5371/iot/devices
headers:
APIKEY:4jggokgpepnvsb2uv4s40d59ov
Fiware-Service:openiot
Fiware-ServicePath:/
Content-Type:application/json
Accept:application/json
body:
{
"devices": [
{ "device_id": "DEV_ID",
"entity_name": "ENTITY_ID",
"entity_type": "thing",
"protocol": "PDI-IoTA-UltraLight",
"timezone": "Europe/Madrid",
"attributes": [
{ "object_id": "t",
"name": "temperature",
"type": "int"
} ],
"static_attributes": [
{ "name": "att_name",
"type": "string",
"value": "value"
}
]
}
]
}
Then I confirm that the device is registered with a GET request to the url http://eidas5.lab.fi-ware.org:5371/iot/devices/DEV_ID
request headers:
APIKEY:4jggokgpepnvsb2uv4s40d59ov
Fiware-Service:openiot
Fiware-ServicePath:/
Content-Type:application/json
Accept:application/json
everything seems ok so far, now I want to check where this device is in the context broker:
According to the docs:
Devices will be represented as NGSI entities in the ContextBroker at 130.206.80.40:1026 (within the FIWARE service-path "OpenIoT").
So with a GET request I should be able to see the new device,but I can't. I even tryed using the fiware-servicepath and fiware-service headers as above, and I can't find it.
Any advice on this?
fiware-service should be open-iot and fiware-servicepath /
have a look at
http://fiwaretourguide.readthedocs.io/en/latest/connection-to-the-internet-of-things/how-to-read-measures-captured-from-iot-devices/

Fiware: Cepheus security considerations?

How can we add security between Orion broker and Cepheus?
How can we use Cepheus with a protected Orion broker (pep is used to secure the access to the broker)?
Thanks and best regards.
Fiware-Cepheus currently does not act as an OAuth client and does not make requests to an IDM server to retrieve the OAuth token by itself.
However Fiware-Cepheus handles the three HTTP headers required by Orion Policy Enforcement Point (PEP) proxies : x-auth-token, fiware-servicepath and fiware-service.
Theses headers values can be set for either Cepheus Broker or Cepheus CEP from configuration settings.
For Cepheus Broker, this configuration is currently static. See Configuration section of the Admin manual.
remote.serviceName=tenant
remote.servicePath=test/example
remote.authToken=OAUTH_TOKEN
For Cepheus CEP, this configuration is more dynamic as it is part of the CEP rules provisioning and can be done independently for each outgoing event. See Configuration section of the User manual.
"out": [
{
"id": "FloorX",
"type": "Floor",
"attributes": [
{
"name": "temperature",
"type": "double",
"metadata": [
{
"name": "unit",
"type": "string"
}
]
}
],
"brokers": [
{
"url": "http://orion.fiware.org:3000",
"serviceName": "tenant",
"servicePath": "test/example",
"authToken": "OAUTH_TOKEN"
}
]
}
]

Fiware Orion Context Broker: Restrictions on subscriptions

Does Orion support restrictions on subscriptions? Ex. I want to receive context updates only when temperature > 30
That functionality is not implemented in NGSIv1, but planned for NGSIv2 (see conditions field in "Subscriptions" at the NGSIv2 draft specification). However, it has not been yet implemented in the last Orion version at the time of writting this (0.25.0).
EDIT: this functionality has been finally implemented in Orion 0.27.0, eg:
POST /v2/subscriptions
...
{
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "device"
}
],
"condition": {
"attributes": [ "temperature" ],
"expression": {
"q": "temperature>30"
}
}
},
"notification": {
"callback": "http://foo.bar:5050/notify",
"attributes": [ ]
},
"expires": "2050-04-05T14:00:00.00Z"
}

Fiware: No observation attributes in Orion CB when registered/sent via IDAS UltraLight

This question is very similar to Missing attributes on Orion CB Entity when registering device through IDAS but found no definitive answer there.
I have been trying FiWare to get UL2.0 via IDAS to the Orion CB working in the Fiware-Lab env:
using latest GitHub
https://github.com/telefonicaid/fiware-figway/tree/master/python-IDAS4
scripts
following the tutorials in particular
http://www.slideshare.net/FI-WARE/fiware-iotidasintroul20v2
I have a FI-WARE Lab account with token generated. Adapted the config.ini file:
[user]
# Please, configure here your username at FIWARE Cloud and a valid Oauth2.0 TOKEN for your user (you can use get_token.py to obtain a valid TOKEN).
username=MY_USERNAME
token=MY_TOKEN
[contextbroker]
host=130.206.80.40
port=1026
OAuth=no
# Here you need to specify the ContextBroker database you are querying.
# Leave it blank if you want the general database or the IDAS service if you are looking for IoT devices connected by you.
# fiware_service=
fiware_service=bus_auto
fiware-service-path=/
[idas]
host=130.206.80.40
adminport=5371
ul20port=5371
OAuth=no
# Here you need to configure the IDAS service your devices will be sending data to.
# By default the OpenIoT service is provided.
# fiware-service=fiwareiot
fiware-service=bus_auto
fiware-service-path=/
#apikey=4jggokgpepnvsb2uv4s40d59ov
apikey=4jggokgpepnvsb2uv4s40d59ov
[local]
#Choose here your System type. Examples: RaspberryPI, MACOSX, Linux, ...
host_type=MACOSX
# Here please add a unique identifier for you. Suggestion: the 3 lower hexa bytes of your Ethernet MAC. E.g. 79:ed:af
# Also you may use your e-mail address.
host_id=a0:11:00
I used the SENSOR_TEMP template, adding the 'protocol' field (PDI-IoTA-UltraLight which as the first problem I stumbled upon):
{
"devices": [
{ "device_id": "DEV_ID",
"entity_name": "ENTITY_ID",
"entity_type": "thing",
"protocol": "PDI-IoTA-UltraLight",
"timezone": "Europe/Amsterdam",
"attributes": [
{ "object_id": "otemp",
"name": "temperature",
"type": "int"
} ],
"static_attributes": [
{ "name": "att_name",
"type": "string",
"value": "value"
}
]
}
]
}
Now I can Register the device ok. Like
python RegisterDevice.py SENSOR_TEMP NexusPro Temp-Otterlo
and see it in Device List:
python ListDevices.py
I can send Observations like
python SendObservation.py Temp-Otterlo 'otemp|17'
But in the ContextBroker I see the Entity but never the measurements, e.g.
python GetEntity.py Temp-Otterlo
Gives
* Asking to http://130.206.80.40:1026/ngsi10/queryContext
* Headers: {'Fiware-Service': 'bus_auto', 'content-type': 'application/json', 'accept': 'application/json', 'X-Auth-Token': 'NULL'}
* Sending PAYLOAD:
{
"entities": [
{
"type": "",
"id": "Temp-Otterlo",
"isPattern": "false"
}
],
"attributes": []
}
...
* Status Code: 200
* Response:
{
"contextResponses" : [
{
"contextElement" : {
"type" : "thing",
"isPattern" : "false",
"id" : "Temp-Otterlo",
"attributes" : [
{
"name" : "TimeInstant",
"type" : "ISO8601",
"value" : "2015-10-03T14:04:44.663133Z"
},
{
"name" : "att_name",
"type" : "string",
"value" : "value",
"metadatas" : [
{
"name" : "TimeInstant",
"type" : "ISO8601",
"value" : "2015-10-03T14:04:44.663500Z"
}
]
}
]
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
}
]
}
I get an TimeInstant attribute strangely. I tried playing with settings of the .ini like fiware-service=fiwareiot, but to no avail. I am out of ideas. The documentation at the catalogue. for IDAS4
is talking about observations to be sent to port 8002 and setting "OpenIoT" service, but that failed as well.
Any help appreciated.
You should run "python SendObservation.py NexusPro 'otemp|17'" instead of "python SendObservation.py Temp-Otterlo 'otemp|17'".
The reason is that you are providing an observation at the southbound and then, the DEV_ID should be used.
The entity does not include an attribute until an observation is received so then it is normal you are not able to see it. Once you try the one above it should all work.
Cheers,