missing support for oauth authentication

[chicco785]

it looks like authentication is supported only via keystone:

https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/command/commandLine.js#L666

but officially oauth is the FIWARE auth protocol.

[chicco785]

@dcalvoalonso @jmcanterafonseca @fgalan @dmoranj

we are working on introducing support for oauth2, and i am looking for some feedbacks.

my current idea is the following:

1. when registering a device (or a service) in the trust field we can store a refresh token (possibly a so called offline_token that have a indefinite life time till it is not used).
2. when an operation toward the context broker is called, the refresh token is used to obtain the access token that is used for the call
3. after the getToken the new generated refresh token is stored in the device or in deviceGroup trust. of course this new operation in the asynchWaterfall does not have sense for Keystone, so it will be done only for the oauth2.

the alternative to this last solution would be to set on the oauth provider the ability to reuse the same token a given number of times, but this is not standard in oauth.

feelings? ideas?

thx, fede

[fgalan]

From my point of view, as long as the current mechanism based in Keystone (i.e. getting the token using POST /v3/auth/token op) is preserved and the new one you are proposing base in OAuth can be implemented without affecting such functionality (maybe using a flag in the config.js file) is ok to go that way.

[chicco785]

absolutely, i will share asap a WIP. i am basically leveraging a similar mechanism to the deviceRegistry one, i.e. at configuration time the actual implementation of the security is configured and then used in the following interactions. I also normalised, as I did for the contextBroker, the configuration to use a url if available rather than host + port, so that also https support can be easily implemented.

[chicco785]

fixed by PR #591

[fgalan]

Once PR #591 has been merged, I wonder if this issue should be closed. From that PR comments:

@fgalan i just realised that for subscriptions created by the IOTA, authorisation is not enabled... am I wrong? in case this would land in a different PR

Should this issue keep opened until that new PR comes? Or is there an independent issue with that piece of work?

[chicco785]

#592 covers subscriptions, but I still need to test it e2e with a real context broker.

[chicco785]

#603 covers registrations and with this all interactions (both for keystone and oauth) are covered.

i will try to create ul agent using the complete set of PR to test in beyond the library