Hi Firzhan, On Wed, Nov 25, 2020 at 5:39 AM Firzhan Naqash <[email protected]> wrote:
> Hi Chanika, > > I assume you are planning to secure the webhook endpoint with the auth > token. In addition, In order to secure the webhook's caller endpoint, are > you planning to implement the request signing methodology at the provider's > end which enables the consumer to determine the origin by signature > verification? > I guess you are referring to the webhook endpoint in here as the API for the initial request. Yes, that would be a REST API call, where it is secured by OAuth token. We do verify the origin of the events, by validating the signature received with events, as we are going to share a security token between GW and the SP. And before sending the event to the consumer's callback URL also, we generate the signature by using the secret given by the consumer and send that along with the event. > > > Are we planning to have a retry mechanism in place at the Provider's end? > I assume you are referring to the retry mechanism implemented in the gateway. Yes, that too will be supported. > > > Regards, > Firzhan > > > email: [email protected] > mobile: (+61) 40 177 5941*| blog: *https://medium.com/@firzhan > *twitter: https://twitter.com/firzhan007 > <https://twitter.com/firzhan007> | linked-in: > **https://www.linkedin.com/in/firzhan > <https://www.linkedin.com/in/firzhan>* > > > On Tue, Nov 24, 2020 at 11:28 PM Chanika Geeganage <[email protected]> > wrote: > >> Hi All, >> >> We are planning to introduce the Streaming API support in APIM 4.0.0 >> release. The streaming API is implemented based on the Async API [1] >> definition. >> >> >> *Stream Provider*: Stream provider will generate an event stream and >> publish to GW via WebSockets/WebHooks/SSE. Stream provider will do all the >> heavy lifting required to generate the final stream. In the case, to stream >> data from other providers such as kafka, NATS, MQTT, which does not work as >> a streaming provider, we have to do the integration via a >> streaming provider such as streaming integrator. >> >> *API Gateway*: Proxy the stream provided by the Stream provider to the >> client via WebSockets/WebHooks/SSE. Further, it will enforce the policies >> and publish stats for monitoring. >> >> In this release we are going to support webhooks [2] as one of the >> protocols for Streaming APIs. Webhooks is a way for an app to provide other >> applications with real-time information. The events are sent to a callback >> url which is registered by the client in the initial request. >> >> >> With API Manager the user flow to support webhooks implementation can be >> illustrated in the following diagram >> >> >> The user flow is similar to REST API apart from the two asynchronous >> message flows in the gateway. As the gateway is stateless, all the requests >> will be proxied to the streaming provider and the events to the client's >> call back URLs. >> >> >> >> 1. We are using websub specification [3] for the message flow >> implementation, due to the fact that it is widely used and descriptive. >> 2. The user specifies the callback URL, topic name and optionally a >> secret in the request. As the topic name comes as a query param in the >> request in the API all initial requests traffic will be forwarded to the >> /* >> resource (without any URL mapping) >> 3. From GW to SP is another webhooks connection. Therefore, a >> publicly available unique URL has to be registered in the SP as the >> gateway >> callback URL for that connection >> 4. To separate out the event traffic and the rest API calls traffic >> we decided to deploy an inbound endpoint as the event receiver (callback >> URL endpoint). >> 5. All the events traffic (for all webhooks APIs) will be received by >> the inbound endpoint. In order to support customized event mediation >> logic, >> the event will be redirected to a resource defined in the API. In that way >> we can have the mediation logic related to both flows (initial request and >> event) in the same API configuration. >> 6. As the GW will proxy the initial request and events (will not >> persist any data), the required information such as client's callback URL, >> subscription ID which are required in the event flow will be appended to >> the callback URL. This is because these two message flows are >> asynchronous, >> and the only reference is the callback URL (ie. the gateway inbound >> endpoint URL). >> >> Your thoughts on this are highly appreciated. >> >> [1] https://www.asyncapi.com/docs/specifications/2.0.0 >> [2] https://github.com/wso2/product-apim/issues/9431 >> [3] https://www.w3.org/TR/websub >> >> >> -- >> >> *Chanika Geeganage* | WSO2 Inc. >> >> (m) +94-77-3522586 | (e) [email protected] >> >> <https://wso2.com/signature> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > -- *Chanika Geeganage* | WSO2 Inc. (m) +94-77-3522586 | (e) [email protected] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
