Hi Amila, Please see my comments below. On Thu, Nov 19, 2020 at 4:35 PM Amila De Silva <[email protected]> wrote:
> Hi Sanjeewa, > The way it is supported for REST APIs right now, the feature operates as > if there was a subscription. The Tier which is typically captured in > Subscription needs to be captured while uploading the certificate. And when > a consumer needs to access the API, a certificate needs to be added against > the API which basically triggers a change in the API. So a change that > needs to happen on Devportal is now happening on the Publisher side. By > supporting uploading certs through the Application; > 1. A Certificate is used as another key for identifying an Application. > 2. API Subscription is enabled uniformly for APIs with Mutual TLS. > In mutual TLS also what we do is, send the user name along with the request (in soap header block). Similar to that, can't we just send this information along with the request(without using a certificate to denote the same). And another concern I had was whether having certificates per app basis is right or not, because when we have a large number of apps then certs can grow. At one point it will be beyond our control. One advantage of what you proposed is, when we renew certificates or revoke(due to sec issues etc) them we can do that without impact to other apps or subscribers. 3. APIs can be consumed without changing the API. > Are we planning to have API level certificate and app level certificate together? Or are we dropping API level certificate features after this introduction. As of now how do we identify certificates for API during the request flow? Is it by looking at API content and then getting certs associated with it? When it comes to apps how can we do this pre check? > > Giving the ability to directly add a certificate to Gateways through > Devportal is a risk, which can be solved through a Workflow. Either through > a Subscription Approval or by triggering a new workflow while uploading the > certificate, wouldn't it be possible to mitigate the risk? > Yes it's doable. But dont we need to check with all certs available in gateways to determine whether to approve or not? Thanks, sanjeewa. > > On Thu, Nov 19, 2020 at 1:14 PM Dulangi Gamage (Intern) <[email protected]> > wrote: > >> Thank you very much for sharing your feedback. We'll take more >> consideration on those matters before proceeding further. >> >> Thank You, >> Dulangi >> >> >> On Thu, Nov 19, 2020 at 12:43 PM Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> As I understand, mutual TLS has nothing to do with the place we upload >>> cerths (application and subscription). >>> If we take mutual SSL enabled soap messages then what we do is get a >>> header block with NS URL after checking cert object. Then from the header >>> block we get the user name. In mutual SSL whatever username send by client >>> is trusted as long as it comes with proper format and along with cert. >>> Similar to that, can't we just let subscribers send those information along >>> with the certificate? >>> >>> On the other hand if we let subscribers upload certs that affect the >>> gateway they can simply upload any certificate with host names and override >>> certificates added by maintainers. Isn't it a problem? >>> >>> Thanks, >>> sanjeewa. >>> >>> On Tue, Nov 17, 2020 at 1:06 PM Dulangi Gamage (Intern) < >>> [email protected]> wrote: >>> >>>> Hi All, >>>> >>>> *Project Description* >>>> >>>> Currently, the API Manager supports mutual TLS at the API level. In the >>>> current implementation application subscription is not permitted for APIs >>>> that are only protected with Mutual SSL. Therefore, subscription or >>>> application-level throttling is not applicable to these types of APIs. >>>> Hence, now the Mutual TLS support needs to be implemented at the >>>> application level so that all the applications subscribed to that API will >>>> have mutual TLS enabled. So my project is to enhance the Mutual TLS support >>>> to the application level and enhance the application developer portal >>>> UI to support mutual TLS. >>>> >>>> Please refer to the attached google doc for more details. >>>> >>>> https://drive.google.com/file/d/1tiB2xkuopKGWWYJYEqTlRztfFiCenl19/view?usp=sharing >>>> >>>> Your feedback and suggestions are greatly appreciated. Thank You. >>>> >>>> >>>> -- >>>> Dulangi Gamage | Intern | WSO2 Inc. >>>> (m) +94766697385 | Email: [email protected] >>>> <http://wso2.com/signature> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> *Sanjeewa Malalgoda* >>> Software Architect | Associate Director, Engineering - WSO2 Inc. >>> (m) +94 712933253 | (e) [email protected] | (b) Blogger >>> <http://sanjeewamalalgoda.blogspot.com>, Medium >>> <https://medium.com/@sanjeewa190> >>> >>> GET INTEGRATION AGILE <https://wso2.com/signature> >>> Integration Agility for Digitally Driven Business >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Dulangi Gamage | Intern | WSO2 Inc. >> (m) +94766697385 | Email: [email protected] >> <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 > -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
