We are evaluating several platforms for integrating a "Smart Energy System".
One important requirement we have to support is multitenancy. From the docs I can see the possibility to start the Orion Context Broker with this option. Orion will ensure the data separation based on the fiware-service request header.
That's fine but how to "secure" this header across the whole software stack (PEP-Proxy, IoT-Agent)?
Which component/device sets this header? Which component ensures that a request with a specific fiware-service header value is authorized to access the data of this tenant?
In my opinion this is a task for Wilma as PEP-Proxy. All traffic to Orion is routed through the PEP-Proxy and the proxy checks if this request is valid. Unfortunately I can not find such a check within the source code nor it is explained in the documentation.
Has someone implemented such an architecture an can help me?
Found another post which answers my question
How to configure access control in Orion NGSI API for tenant isolation using Wilma PEP Proxy and IdM Keyrock?
We will have to implement this kind of authorization for our own.
Related
I hope I'll find a reply to a bad (for me) question for which i don't find an answer at the moment.
I have to synchronize information between an enterprise asset management software, based on IBM Maximo, and an external data lake. In order to achieve this target I can develop a custom API gateway useful to receive any update/insert of data in Maximo. Or, I could use FIWARE Context Broker developing a custom data model for my asset management entities (and relationship) in order to store data having benefits in terms of NGSI protocol.
Both FIWARE Context Broker or API Gateway can be extended in order to provide public services to an IoT platform or other systems of third parties. So, why shall I use FIWARE Context Broker or a custom API Gateway? What's your advice and considerations?
I put below an example of a generic architecture
Thank you so much for any reply.
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?
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.
I read "Those who would like to enjoy the binding, presentation model structuring, testing capabilities, toolkit independence, and all the other benefits of OpenDolphin, but prefer REST (or other) remoting for data access, can use OpenDolphin with the in-memory configuration"
But I could not find any further hints in the docs?
I can't rely on sticky sessions in my load balanced webserver.
Therefore I need to plugin something different for the http session state.
Is there a opendolphin config property prepared for this? If not are there any plugin points available?
since OpenDolphin and Dolphin Platform use the remote presentation model pattern to synchronize presentation models between client and server you need a state on the server. Currently this state is defined in the session. As you said it's no problem to use load balancing with sticky sessions to provide several server instances. If you need dynamic updates between the clients a distributed event bus like hazelcast will help.
Therefore I need to plugin something different for the http session
state.
What do you need? With the last version (0.8.6) of Dolphin Platform you can access the http client in the client API and provide custom headers or cookies. Will this help? Can you please tell us what you need or open an issue at the Dolphin Platform github repo?
I'm trying to integrate Proton CEP and Mandrill, an email service, mediated by Orion context broker.
When I was starting to study Orion, I thought that it would be able to communicate directly with CEP, exchanging JSON objects through http. And also that Orion would be able to parse each object to deliver to the correct format understandable by each API.
From the examples and documentation available I was able to understand that another API developed by us should be doing the parsing and mediating the communications between each API.
So I'd like to confirm that this is so and that I'm not missing something. Is Orion indeed unable to customize its outputs?
If confirmed, then I will proceed with development of this mediating API.
Arthur
Edit:
I believe I wasn't clear above about the issue. I hope adding this helps.
Proton CEP recieves through http POST JSON objects, but it only understands the variables if they are in simple format, like {"Name1":"Value1","Name2":"Value2"}, with no arrays or complex struture.
Orion, can comunicate in JSON as well through http, but I can't control the structure of the JSON output. So the result is that CEP wouldn't be able to understand inputs from Orion and process them. The same issue arises with other APIs too. And I'd like to confirm that Orion is indeed unable to custom its output and that this integration needs to be done on our side.
You can find best explanation about connection between CEP and Orion in latest guides.
User guide's Appendix A specifies steps to establish such a communication (subscription(s) and/or simple publish).
Orion only understands/returns XML and JSON, and with this it is able to communicate with most of the GEs in FIWARE. I can't tell you anything about the Proton CEP, sorry.
To make sure you have interoperability between GEs (and especially other components) a "mediating gateway" will solve the problem, of course.
The JSON format that Orion Context Broker sends in notification conforms to the NGSI10 context management specification. Using a predefined JSON (instead of a custom one) is the best way to ensure that interoperability with other NGSI-compliant software works.
Before doing the NGSI-to-Proton adaptation piece yourself, I'd recomend you to check with Proton development team if there is any existing NGSI connector to their system that you can reuse. You can find contact details in Proton page at FIWARE catalogue.
is either of the two available PEP proxies for Orion (i.e. either /fiware-orion-pep or /fi-ware-pep-proxy) able to use Keycloak's IDM instead of Keystone's ? if not, are there plans to make this functionality available?
I'm afraid they aren't. About the inclusion in the roadmap, it is not expected AFAIK, at least in 'fiware-orion-pep'. There are means, though, to integrate Keystone with other authentication providers (SAML, OpenID...), so maybe you should try to integrate THROUGH Keystone instead of replacing it with other authentication provider.