iotagent-node-lib icon indicating copy to clipboard operation
iotagent-node-lib copied to clipboard

authentication keystone

Open caiothomas opened this issue 9 years ago • 5 comments

Hi, I'm using Keystone and PEP Proxy to perform authentication on Orion requests.

The PEP Proxy is running on port 1026 and the Keystone on port 5000. Tests using the x-auth-token in a queryContext request on port 1026 worked correctly. When using the IoT Agent I put the configuration in the config.js file

Config.authentication = { enable: true, host: 'localhost', port: '5000', user: 'username', password: 'password' };

The configuration file provided below is correct? When I did a device register, the IoTAgent didn't authentication to get the token. Does anyone know what it can be?

Thanks in advance.

Best Regards, Caio Thomas Oliveira

caiothomas avatar Dec 12 '16 18:12 caiothomas

The IoT Agent authenticates against the Context Broker just when there is a Trust token associated with the Device (you can do that with the trust provisioning attribute). You can find the documentation here.

dmoranj avatar Dec 19 '16 11:12 dmoranj

Hi,

I believe I have followed the documentation processes correctly. However, the IoT Agent did not make a request in Keystone.

In Keystone, I ran the trust command:

openstack trust create --role admin --impersonate --project /ufu admin room1

And this request with the token also works:


curl http://localhost:5000/v3/OS-TRUST/trusts \
    -s \
    -H "X-Auth-Token: gAAAAABYWCxDyKE4IP_lzUaRo1I075y7_M96FXO4s9G0tY9HpdeHV8H_wyrzzpqCEOBIwaNv8yKADPX8w5zr4NyV1vN62AHqgo42PoTpHr_zbTm7_oF0bzkmfOnXSsq--Wf5PxHnQoDQpUrOaF71BYWM3-7sphZyRg" \
    -H "Content-Type: application/json" \
    -d '
{
    "trust": {
        "impersonation": false,
        "project_id": "5657f6135c4346b1b2d2b4b9fa8b385d",
        "roles": [
            {
                "id": "0946b3e7f7e34a9ea85ce5e7c0b2aeab"
            }
        ],
        "trustee_user_id": "f8454b3b20714bc1b4e72727d90722ea",
        "trustor_user_id": "58087e8a85ce4a67a6f92146be501039"
    }
}'

In types I put the trust id. However, when the IoT agent registers it is not sending this trust on headers.


{
    "url": "http://localhost:1026/NGSI9/registerContext",
    "method": "POST",
    "json": {
        "contextRegistrations": [
            {
                "entities": [
                    {
                        "type": "Room",
                        "isPattern": "false",
                        "id": "Room1"
                    }
                ],
                "attributes": [
                    {
                        "name": "pressure",
                        "type": "string",
                        "isDomain": "false"
                    },
                    {
                        "name": "temperature",
                        "type": "centigrades",
                        "isDomain": "false"
                    },
                    {
                        "name": "turn",
                        "type": "string",
                        "isDomain": "false"
                    }
                ],
                "providingApplication": "http://localhost:4061"
            }
        ],
        "duration": "P1Y"
    },
    "headers": {
        "fiware-service": "figuardian",
        "fiware-servicepath": "/ufu"
    }
}

The security function in IoT Agent working properly?

Best Regards, Caio Thomas Oliveira

caiothomas avatar Dec 19 '16 20:12 caiothomas

Hello, I ran iotagent-ul (the version used is 1.4.0) and checked a iotagent-node-lib library.

First I registered a service.

curl -X POST -H "Fiware-Service: figuardian" -H "Fiware-ServicePath: /ufu" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
  "services": [
    {
      "type": "Room",
      "apikey" : "apikey2",
      "resource": "/iot/teste",
      "trust": "8970A9078A803H3BL98PINEQRW8342HBAMS",
      "cbHost": "http://unexistentHost:1026",
            "attributes": [
                  { "object_id": "t", "name": "temperature", "type": "float" }
            ],
            "lazy":[
                  { "object_id": "p", "name": "pressure", "type": "string" }
            ],
            "commands": [
                  { "object_id": "z", "name": "turn", "type": "string" }
            ]
  
    }
  ]
}' 'http://localhost:4061/iot/services'

Then I registered a device.

curl -X POST -H "Fiware-Service: figuardian" -H "Fiware-ServicePath: /ufu" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
    "devices": [
        {
            "device_id": "sensor01",
            "entity_name": "Room1",
            "entity_type": "Room",
            "attributes": [  { "object_id": "t", "name": "temperature", "type": "float" }

],
            "lazy":[],
            "commands": [],            
            "static_attributes": [
          { "name": "serialID", "type": "02598347" }
          ]

        }
    ]
}' 'http://localhost:4061/iot/devices'

When I register the device, no authentication request is made. The function that is called "sendRegistrations" in the file "iotagent-node-lib / lib / services / devices / registrationUtils.js" and after "createInitialEntity" in the file "lib / services / devices / deviceService.js". Theses functions does not make any authentication token requests.

It was possible to notice some bugs. The device does not use the "apikey", "trust" and "cbHost" of the service registered. When it does the registry uses the "config.getConfig (). ContextBroker.host" and the "trust" has null values on "updateContext".

Response of request with url of contexbroker from config file and "X-Auth-Token": null.

{
    "url": "http://localhost:10026/v1/updateContext",
    "method": "POST",
    "headers": {
        "fiware-service": "figuardian",
        "fiware-servicepath": "/ufu",
        "X-Auth-Token": null
    },
    "json": {
        "contextElements": [
            {
                "type": "Room",
                "isPattern": "false",
                "id": "Room1",
                "attributes": [
                    {
                        "name": "p",
                        "type": "string",
                        "value": "19"
                    },
                    {
                        "name": "serialID",
                        "type": "02598347"
                    }
                ]
            }
        ],
        "updateAction": "UPDATE"
    }
}

Am I running the calls correctly?

Best Regards, Caio Thomas Oliveira

caiothomas avatar Dec 29 '16 00:12 caiothomas

Hello, sorry for the late response. The authentication features of the IoTAgent library are not commonly used (as the IoT Agents are usually deployed in the same network segment as the Context Broker, inside a secure network) so there may be some bugs in the authentication part of the library.

First things first, the sendRegistrations doesn't make use of the security token, so that's clearly a bug. I'll write it down in an issue. Registrations are only used for commands and lazy operations, so most probably this indicates we didn't try the security features with neither one nor the other.

On the other hand, you said that "The device does not use the "apikey", "trust" and "cbHost" of the service registered.", and that's quite more intriguing. Even if the security features are not working, the "apikey" is used every day, so there must be something wrong in your current provisioning. Did you get any error in any of the provisionings? I suggest you put the IoTA in DEBUG mode to check for errors, as there may be some problems there.

dmoranj avatar Dec 29 '16 08:12 dmoranj

Hello,

I'm doing test with iotagent-ul. The previous report on "apikey", "trust" and "cbHost" I checked what can be. When making a register a service and device these attributes are not used.

I sending a message MQTT using the "apikey" associated with this service and didn't work. But it worked with the default apikey from config.js file. Should not it be the service apikey?

I also noticed that the createInitialEntity (/lib/services/devices/deviceService.js), sendRegistrations(/lib/services/devices/registrationUtils.js) and createRequestObject (/lib/services/ngsi/ngsiService.js) functions do not get the cbHost from service.

Note that the "subscribe" function from /lib/services/ngsi/subscriptionService.js has a check condition.

   if (device.cbHost) {
        options.uri = 'http://' + device.cbHost + '/v1/subscribeContext';
    } else {
        options.uri = 'http://' + config.getConfig().contextBroker.host + ':' +
            config.getConfig().contextBroker.port + '/v1/subscribeContext';
    }

Should not this condition be on other calls?

caiothomas avatar Jan 03 '17 17:01 caiothomas