Re: [Architecture] [APIM][Intern Project]- Application Level Mutual TLS support for API Manager

[Sanjeewa Malalgoda]

Hi Amila,
Please see my comments below.

On Thu, Nov 19, 2020 at 4:35 PM Amila De Silva  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) 
> 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 
>> 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) <
>>> dula...@wso2.com> 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: dula...@wso2.com
 
 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

>>>
>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>> , Medium
>>> 
>>>
>>> GET INTEGRATION AGILE 
>>> Integration Agility for Digitally Driven Business
>>> _

Re: [Architecture] [APIM][Intern Project]- Application Level Mutual TLS support for API Manager

[Amila De Silva]

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.
3. APIs can be consumed without changing the API.

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?

On Thu, Nov 19, 2020 at 1:14 PM Dulangi Gamage (Intern) 
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 
> 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) 
>> 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: dula...@wso2.com
>>> 
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>> , Medium
>> 
>>
>> GET INTEGRATION AGILE 
>> Integration Agility for Digitally Driven Business
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Dulangi Gamage | Intern | WSO2 Inc.
> (m) +94766697385 | Email: dula...@wso2.com
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Amila De Silva*
Software Architect | Associate Director, Engineering - WSO2 Inc.
(m) +94 775119302 | (e) ami...@wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] - Event Based API Deployment architecture.

[Nirmal Fernando]

On Thursday, November 19, 2020, Tharindu Dharmarathna 
wrote:

> Hi All,
>
> Currently, WSO2 API Manager has the following two methods of deploying
> artifacts into the Gateway deployments.
>
>1. Push API artifacts into Gateway nodes.
>2. Pull Gateway Artifacts from Traffic Manager nodes based on the
>event.
>
> from the next APIM release, we will be going to remove the [1] option and
> we going to make [2] the way of deploying APIS.
>

> *Problems come in [2] architecture implemented.*
>

How are we handling the failure scenarios? What happens if an event from
publisher to TM lost? What happens if an event from TM to gateway lost?

1. Introducing a new Gateway Type (Envoy Micro Gateway, etc) couldn't use
> existing event-based architecture since it handles only the synapse
> artifacts at the publisher end.
>
> *Solution*
> The following model going to be implemented based on the above points as
> discussed.
>
> [image: deployment.png]
> Your feedback on the above implementation is highly appreciated.
>
> Thanks
>
> *Tharindu Dharmarathna*Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091*
>


-- 

Thanks & regards,
Nirmal


*Nirmal Fernando* | Senior Lead Solutions Engineer | WSO2 Inc.
(m) +94 71 5779733 | (e) nir...@wso2.com

[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] - Event Based API Deployment architecture.

[Sanjeewa Malalgoda]

When it comes to hybrid deployment i guess publisher and TM both will
reside on cloud. In that case we will need to use an adapter for onprem
deployment to connect with cloud.
Considering that we can draw the same with the adapter. Adapters can be
gateway type specific but always need to communicate with traffic managers
using the same protocol.
Adapter to gateway communication can be selected based on the gateway
type(xds for envoy etc). Default adapter which allows synapse gateway to
communicate with traffic manager can be built into traffic manager for
default cases. When hybrid mode used can be separated and brought into
onprem. So those who use all in one pack or having simple deployments won't
notice any complexity. Thoughts?

Thanks,
sanjeewa.




On Thu, Nov 19, 2020 at 3:25 PM Tharindu Dharmarathna 
wrote:

> Hi All,
>
> Currently, WSO2 API Manager has the following two methods of deploying
> artifacts into the Gateway deployments.
>
>1. Push API artifacts into Gateway nodes.
>2. Pull Gateway Artifacts from Traffic Manager nodes based on the
>event.
>
> from the next APIM release, we will be going to remove the [1] option and
> we going to make [2] the way of deploying APIS.
>
> *Problems come in [2] architecture implemented.*
> 1. Introducing a new Gateway Type (Envoy Micro Gateway, etc) couldn't use
> existing event-based architecture since it handles only the synapse
> artifacts at the publisher end.
>
> *Solution*
> The following model going to be implemented based on the above points as
> discussed.
>
> [image: deployment.png]
> Your feedback on the above implementation is highly appreciated.
>
> Thanks
>
> *Tharindu Dharmarathna*Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091*
>


-- 
*Sanjeewa Malalgoda*
Software Architect | Associate Director, Engineering - WSO2 Inc.
(m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
, Medium


GET INTEGRATION AGILE 
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] - Event Based API Deployment architecture.

[Tharindu Dharmarathna]

Hi All,

Currently, WSO2 API Manager has the following two methods of deploying
artifacts into the Gateway deployments.

   1. Push API artifacts into Gateway nodes.
   2. Pull Gateway Artifacts from Traffic Manager nodes based on the event.

from the next APIM release, we will be going to remove the [1] option and
we going to make [2] the way of deploying APIS.

*Problems come in [2] architecture implemented.*
1. Introducing a new Gateway Type (Envoy Micro Gateway, etc) couldn't use
existing event-based architecture since it handles only the synapse
artifacts at the publisher end.

*Solution*
The following model going to be implemented based on the above points as
discussed.

[image: deployment.png]
Your feedback on the above implementation is highly appreciated.

Thanks

*Tharindu Dharmarathna*Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94779109091*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture