search

FIWARE / context.Orion-LD

Context Broker and CEF building block for context data management which supports both the NGSI-LD and the NGSI-v2 APIs
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.06.01_60/gs_CIM009v010601p.pdf
GNU Affero General Public License v3.0
50 stars 41 forks source link

Feature request: Proxy protocol for outgoing notifications #766

Open gboege opened 3 years ago

gboege commented 3 years ago

Data Spaces are gaining more importance in Europe (IDSA, GAIA-X, i4Trust). The brings more importance to Broker Federation to realize Broker Networks that can do distributed computing ML/AI/CEP...

In DataSpaces like IDSA, all messages have to be equipped with individual information that is hardly available in Orion-LD.

The concept could be easily realized with the proxy protocol: https://www.haproxy.com/de/blog/haproxy/proxy-protocol/ This sends the HTTP POST Call of the notification to a specific URL to prepare and equip the outgoing message with additional security features, without losing the final receipient URL info.

Today this concept was realized with some kind of hack to an Istio Service Mesh, realizing a catch-all function to all outgoing notifications to a specific URL with putting the receipient URL in a kind of a backsack for later interpretation.

This concept demands a service mesh, i.e. with the Envoy Proxy and is a bit against the normal rules.

Implementing the well established and standardized Proxy Protocol for outgoing notifications could solve this issue and would enable the concept of Context Broker even more for working in data spaces.

kzangeli commented 2 years ago

Did we say that this was no longer necessary ... ?

wistefan commented 2 years ago

This can be applied by using the https://github.com/FIWARE/endpoint-auth-service Currently, plain envoy sidecar and the Openshift ServiceMesh is supported and only an auth-provider for IShare is available. Please create an issue with your requirements there.

kzangeli commented 2 years ago

Good, then I close this issue

gboege commented 2 years ago

Yes, if we consider the envoy sidecar "plugin" solution, it could replace the proxy protocol. In the first step, this would only mean to route all outgoing traffic to the IDS Connector without altering anything. Envoy catches all outgoing traffic via IP-Tables. But did we already bury this issue finally (use cases who do not use envoy?)

wistefan commented 2 years ago

I don't understand the routing part. The sidecar does only apply auth-information to the request, it does not do any re-routing.

kzangeli commented 2 years ago

I assumed that the envoy idea was to replace any implementation that could be done for the broker. Maybe I misunderstood.

gboege commented 2 years ago

@wistefan the routing part was to let all outgoing traffic be routed to the IDS Connector to add all IDS relevant information to the headers. Today we bypass this with additional headers. We thought about the plugin solution and then it was already ready and there from you. So we did not pick up and cleared the prior question.