3

I have to think about an architecture using FIWARE orion context-broker and several IoT agents/context-provider. In the documentation is a section describing how to securue the communication from an IoT agent/context-provider to orion. But how to secure the other sider? What I understand, so far, is that a context-provider has to expose a REST endpoint (/op/query) on which it accepts incomming traffic. But how do it can make sure, that these request are valid? In case of a subscription you can use httpCustom instead of http in the provider section, when you create a subscription. With this it is possible to use a static token which will be used by orion, when making request to the given url. This isn't possible for registration. Any suggestions how a context-provider/IoT agent can decide if an incoming request is a valid one?

piwo1984
  • 71
  • 6
  • Not sure how *NGSI-v2* does this with the `/op/query` endpoint, but *NGSI-LD* registrations on Orion-LD forwards incoming headers, so an input `Authenticate` header on the broker would also appear on the request sent to the registred context provider. – Jason Fox Apr 09 '21 at 14:40
  • 1
    This is not an option 'cause `ngsi-ld` isn't final yet. – piwo1984 Apr 13 '21 at 07:28
  • Not sure if I'm getting your point... what do you mean by "valid" in "But how do it can make sure, that these request are valid?" Maybe editing the question to add an example of the "reference case" in subscriptions you want to mimic with registrations/CPrs may help to clarify. Thanks! – fgalan Apr 20 '21 at 14:49
  • I mean: how to make sure that the requester is an authorized one. – piwo1984 Apr 23 '21 at 06:17

1 Answers1

2

With NGSIv2 Subscription/Notification and Register/Forwarding you will receive an X-Auth-Token Header with the token used in the initial update operation. You should be able to check within the IDM (Keystone in our Stack).

As a workaround you may use the value itself to send some kind of Apikey along with the real value.

Network security may apply also, it is common to use firewalls and restrict ip/ports, or stablish APN/VPN at distributed architectures (at least with unsecured devices or external networks).

Last, if synchronous communication is not a must for your use case (registers are sync, sub/notif are async), it is not a big deal to use Subs/Notif mechanism to communicate with a Context Adapter. We do sometimes, registers are tricky and troublesome.

Best.

Perrolobo
  • 543
  • 3
  • 14
  • Let me remark that NGSIv2 is stable and mature. Its evolution, as NGSIv2 is under a continuous improvement lifecycle, takes special care of backwards compatibility with prior versions and use case scenarios. NGSIv2 is widely used in real projects and production environments. – Perrolobo Apr 20 '21 at 18:49
  • "With NGSIv2 Subscription/Notification and Register/Forwarding you will receive an X-Auth-Token Header with the token used in the initial update operation. You should be able to check within the IDM (Keystone in our Stack)." I haven't read anything about it. Where is the description of this functionality? – piwo1984 Apr 23 '21 at 06:21
  • I'm afraid it's not properly documented, at least I can't find explicit documentation at implementation PR. This should be the issue: https://github.com/telefonicaid/fiware-orion/issues/715 and the test use case https://github.com/telefonicaid/fiware-orion/blob/master/test/functionalTest/cases/0715_forward_xauth_token_to_cprs/propagate_xauth_token_for_update_and_query_standard_ops.test – Perrolobo Apr 24 '21 at 07:59