context.Orion-LD
context.Orion-LD copied to clipboard
FIWARE
Feature request: Proxy protocol for outgoing notifications
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.
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.
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?)
I don't understand the routing part. The sidecar does only apply auth-information to the request, it does not do any re-routing.
I assumed that the envoy idea was to replace any implementation that could be done for the broker. Maybe I misunderstood.
@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.