Hi Amila, Thank you so much for your suggestion. This way of subscribing the APIs will be possible to do so. I will look into it further and get back to you.
On Fri, Aug 14, 2020 at 9:29 AM Amila De Silva <[email protected]> wrote: > Hi Ziyam, > The reason to ask about uploading client certificates was to know whether > we already identified an approach to do so. Even if there's a management > API, IMO it should be invoked by a DevOps who has permission to change > configuration. > > One suggestion would be : > From the Devportal side it'll be sufficient to provide an option to attach > a certificate to the Application. So in order to consume the Kafka API, > Developers need to create an Application and Subscribe to the API, but > instead of creating Consumer Key/Secret, in this instance they'd have to > attach a certificate. At the time of subscribing, Devportal would also > generate the relevant rules associated with the client. Then as a part of > the Subscription approval flow, an admin can verify the cert and apply it > to Kafka with the relevant ACLs. (Admins can either use the exact rules or > define their own rules by looking at the generated rules. The idea behind > generating rules is to save the trouble of going through API definition and > identifying the needed access levels.) Approval will only be completed > once the new certs has been applied properly. > > > On Wed, Aug 12, 2020 at 10:09 AM Ziyam Santhosh (Intern) <[email protected]> > wrote: > >> Hi Amila, >> >> Sorry for the late reply. I did some research regarding your question. >> Yes, client authentication is achieved using mutual SSL. As far as I know, >> there isn't any management APIs in Kafka to apply ACLs and uploading >> certificates. But [1] >> <https://github.com/simplesteph/kafka-security-manager> This may help us >> to do that. I am still not sure about the functionalities of this tool. I >> will update you soon. >> >> [1] https://github.com/simplesteph/kafka-security-manager >> >> On Thu, Aug 6, 2020 at 12:46 PM Amila De Silva <[email protected]> wrote: >> >>> Hi Ziyam, >>> >>> Thanks for the clarification. As I understand [1],Client Authentication >>> is achieved through Mutual SSL, which means that when creating a >>> subscription each client app should be able to upload their certificate, >>> isn't it? And are there any management APIs in Kafka that allows applying >>> ACLs and uploading certificates, or do we plan to do it manually? >>> >>> [1] >>> https://kafka.apache.org/20/documentation/streams/developer-guide/security.html >>> >>> On Wed, Aug 5, 2020 at 3:39 PM Ziyam Santhosh (Intern) <[email protected]> >>> wrote: >>> >>>> Hi Amila! >>>> Basically Kafka topics and streams have their own security policies >>>> applied through certificates which determine what users can do with those >>>> topics such as read-only or read and write authorities. Our developer >>>> portal will be the issuer of these certificates. These certificates will be >>>> issued to people who have a valid subscription to the API. >>>> >>>> On Wed, Aug 5, 2020 at 8:04 AM Nuwan Dias <[email protected]> wrote: >>>> >>>>> [Adding Frank and Vanji] >>>>> >>>>> On Tue, Aug 4, 2020 at 5:05 PM Amila De Silva <[email protected]> wrote: >>>>> >>>>>> Hi Ziyam, >>>>>> >>>>>> On Tue, Aug 4, 2020 at 1:48 PM Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> [Adding Frank and Vanji] >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 1:26 PM Ziyam Santhosh (Intern) < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Introduction to AsyncAPI specification >>>>>>>> >>>>>>>> *Nowadays, AsyncAPI is one of the most popular topics in the world >>>>>>>> of event-driven APIs. Earlier, There was a need for a tool to specify >>>>>>>> and >>>>>>>> document the event-driven APIs where OpenAPI specifications are >>>>>>>> restricted >>>>>>>> only to document REST APIs. Then after, AsyncAPI specification was >>>>>>>> introduced to document the specifications for event-driven APIs. There >>>>>>>> are >>>>>>>> many similarities between OpenAPI specifications and AsyncAPI >>>>>>>> specifications because AsyncAPI was inspired by OpenAPI. Keywords can >>>>>>>> be >>>>>>>> mentioned as one of the major differences between them. (Eg: The >>>>>>>> endpoints >>>>>>>> of the REST API are called as paths and endpoints of Event-driven API >>>>>>>> are >>>>>>>> called as channels).*Why AsyncAPI for WSO2 API Manager? >>>>>>>> >>>>>>>> *AsyncAPI specification helps to understand the defined APIs for >>>>>>>> both humans and machines. This makes it more special to be used by >>>>>>>> most of >>>>>>>> the developers. Enabling the usage of AsyncAPI specifications in WSO2 >>>>>>>> API >>>>>>>> manager will help our developers and consumers to easily work with >>>>>>>> event-driven APIs within our product.*Objectives of the project >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> Users will be able to use existing Websocket or Kafka endpoints >>>>>>>> to create event-driven APIs by importing their AsyncAPI >>>>>>>> specifications. >>>>>>>> 2. >>>>>>>> >>>>>>>> Application developers will be able to subscribe to those >>>>>>>> event-driven APIs and be allowed to consume WebSockets and Kafka >>>>>>>> streams. >>>>>>>> >>>>>>>> Importing AsyncAPI specifications >>>>>>>> >>>>>>>> *API Manager already supports WebSockets. After the implementation >>>>>>>> of this project, A WebSocket can be easily created by importing its >>>>>>>> AsyncAPI specification. Kafka is a distributed streaming platform which >>>>>>>> helps to build event-driven applications. These applications may have >>>>>>>> event-driven APIs. These APIs which are created using Kafka protocols >>>>>>>> can >>>>>>>> be described using AsyncAPI specifications. By importing these >>>>>>>> specifications into the APIM, we can enable the application developers >>>>>>>> to >>>>>>>> consume Kafka streams by subscribing to these APIs. This will be a new >>>>>>>> feature for our APIM.* >>>>>>>> Subscribing to event-driven APIs >>>>>>>> >>>>>>>> When an application developer subscribes to consume a WebSocket >>>>>>>> API, that particular WebSocket API’s proxy will be created in our API >>>>>>>> Gateway. So the gateway endpoint of that API will be used by the >>>>>>>> consumer. >>>>>>>> But, when a consumer subscribes for a Kafka endpoint API, there won’t >>>>>>>> be >>>>>>>> any mediator like API gateway between them. The Kafka endpoint itself >>>>>>>> will >>>>>>>> be used by the consumer. Still, not all Kafka Streams are free to use. >>>>>>>> There are security policies for some Kafka Streams which require >>>>>>>> certificates to use those streams. WSO2 APIM will be the provider of >>>>>>>> those >>>>>>>> certificates for our consumers to subscribe to the Kafka streams. >>>>>>>> >>>>>>> So if this was correctly understood, only WebSocket APIs will be >>>>>> secured and Throttled through the Gateway, Kafka Streams are only >>>>>> registered as APIs to make them more discoverable (and maybe Kafka >>>>>> Streams >>>>>> are only exposed as internal APIs). Application on DevPortal is only >>>>>> needed >>>>>> when consuming the WebSocket API. >>>>>> If the above is correct, the part about APIM providing certificates >>>>>> to consume Kafka streams isn't clear. Can you please explain that a bit? >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards,-- >>>>>>>> *Ziyam Santhosh* >>>>>>>> Software Engineering Intern | WSO2 >>>>>>>> >>>>>>>> Email: [email protected] >>>>>>>> Mobile: +94752204021 >>>>>>>> Web: http://wso2.com >>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Nuwan Dias* | Senior Director | WSO2 Inc. >>>>>>> (m) +94 777 775 729 | (e) [email protected] >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Amila De Silva* >>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>>>>> (m) +94 775119302 | (e) [email protected] >>>>>> <http://wso2.com/signature> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Nuwan Dias* | Senior Director | WSO2 Inc. >>>>> (m) +94 777 775 729 | (e) [email protected] >>>>> >>>> >>>> >>>> -- >>>> *Ziyam Santhosh* >>>> Software Engineering Intern | WSO2 >>>> >>>> Email: [email protected] >>>> Mobile: +94752204021 >>>> Web: http://wso2.com >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> *Amila De Silva* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 775119302 | (e) [email protected] >>> <http://wso2.com/signature> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> *Ziyam Santhosh* >> Software Engineering Intern | WSO2 >> >> Email: [email protected] >> Mobile: +94752204021 >> Web: http://wso2.com >> [image: http://wso2.com/signature] <http://wso2.com/signature> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Amila De Silva* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 775119302 | (e) [email protected] > <http://wso2.com/signature> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Ziyam Santhosh* Software Engineering Intern | WSO2 Email: [email protected] Mobile: +94752204021 Web: http://wso2.com [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
