Re: [Architecture] Using Kubernetes ConfigMaps for Managing Product Configurations

[Imesh Gunaratne]

On Tue, Sep 12, 2017 at 10:43 PM, Pubudu Gunatilaka 
wrote:

> Hi Lakmal,
>
> Yes, it is the base image. As we discussed offline, I will add the jks
> files to the base image. We will update the documentation with this
> information.
>

​+1​

>
> Thank you!
>
> On Wed, Sep 13, 2017 at 11:10 AM, Lakmal Warusawithana 
> wrote:
>
>> You mean [2] base right? +1 for option one.
>>
>> [2] https://github.com/wso2/kubernetes-apim/tree/2.1.0/base/apim
>>
>> On Wed, Sep 13, 2017 at 10:53 AM, Pubudu Gunatilaka 
>> wrote:
>>
>>> Hi,
>>>
>>> Config maps do not support binary files [1] at the moment. How do we
>>> handle binary files such as jks?
>>>
>>> *Option 1*
>>>
>>> Add those files to the base image. Then we can pass an ARG and based on
>>> that we can replace the product vanilla files.
>>>
>>> *Option 2*
>>>
>>> Create another docker image for all the patterns based on the base
>>> image. Maybe we can include any pattern specific artifacts and binary files
>>> in this.
>>>
>>> Appreciate your thoughts on this.
>>>
>>> [1] - https://github.com/kubernetes/kubernetes/issues/32432
>>>
>>> Thank you!
>>>
>>> On Tue, Sep 12, 2017 at 12:05 PM, Imesh Gunaratne 
>>> wrote:
>>>


 On Sun, Sep 10, 2017 at 9:54 AM, Youcef HILEM 
 wrote:

> Hi All,
>
> Thank you all.
> A PR has just been submitted
> (https://github.com/wso2/kubernetes-apim/pull/27).
> I will be able to start testing on openshift 3.4.
> With this flexibility I can really adapt easily and efficiently to our
> different constraints without the cumbersome to create as many docker
> images
> as it was before.
>

 ​Great! Nice to hear that Youcef!

 Thanks
 Imesh
 ​

>
> Thanks again.
>
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.
> n7.nabble.com/WSO2-Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



 --
 *Imesh Gunaratne*
 Associate Director/Architect
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
 W: https://medium.com/@imesh TW: @imesh
 lean. enterprise. middleware


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


>>>
>>>
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Senior Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Senior Director - Cloud Architecture; WSO2 Inc.
>> Mobile : +94714289692 <+94%2071%20428%209692>
>> Blogs : https://medium.com/@lakwarus/
>> http://lakmalsview.blogspot.com/
>>
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Kubernetes ConfigMaps for Managing Product Configurations

[Lakmal Warusawithana]

You mean [2] base right? +1 for option one.

[2] https://github.com/wso2/kubernetes-apim/tree/2.1.0/base/apim

On Wed, Sep 13, 2017 at 10:53 AM, Pubudu Gunatilaka 
wrote:

> Hi,
>
> Config maps do not support binary files [1] at the moment. How do we
> handle binary files such as jks?
>
> *Option 1*
>
> Add those files to the base image. Then we can pass an ARG and based on
> that we can replace the product vanilla files.
>
> *Option 2*
>
> Create another docker image for all the patterns based on the base image.
> Maybe we can include any pattern specific artifacts and binary files in
> this.
>
> Appreciate your thoughts on this.
>
> [1] - https://github.com/kubernetes/kubernetes/issues/32432
>
> Thank you!
>
> On Tue, Sep 12, 2017 at 12:05 PM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Sun, Sep 10, 2017 at 9:54 AM, Youcef HILEM 
>> wrote:
>>
>>> Hi All,
>>>
>>> Thank you all.
>>> A PR has just been submitted
>>> (https://github.com/wso2/kubernetes-apim/pull/27).
>>> I will be able to start testing on openshift 3.4.
>>> With this flexibility I can really adapt easily and efficiently to our
>>> different constraints without the cumbersome to create as many docker
>>> images
>>> as it was before.
>>>
>>
>> ​Great! Nice to hear that Youcef!
>>
>> Thanks
>> Imesh
>> ​
>>
>>>
>>> Thanks again.
>>>
>>> Youcef HILEM
>>>
>>>
>>>
>>> --
>>> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architectur
>>> e-f62919.html
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Associate Director/Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Kubernetes ConfigMaps for Managing Product Configurations

[Pubudu Gunatilaka]

Hi,

Config maps do not support binary files [1] at the moment. How do we handle
binary files such as jks?

*Option 1*

Add those files to the base image. Then we can pass an ARG and based on
that we can replace the product vanilla files.

*Option 2*

Create another docker image for all the patterns based on the base image.
Maybe we can include any pattern specific artifacts and binary files in
this.

Appreciate your thoughts on this.

[1] - https://github.com/kubernetes/kubernetes/issues/32432

Thank you!

On Tue, Sep 12, 2017 at 12:05 PM, Imesh Gunaratne  wrote:

>
>
> On Sun, Sep 10, 2017 at 9:54 AM, Youcef HILEM 
> wrote:
>
>> Hi All,
>>
>> Thank you all.
>> A PR has just been submitted
>> (https://github.com/wso2/kubernetes-apim/pull/27).
>> I will be able to start testing on openshift 3.4.
>> With this flexibility I can really adapt easily and efficiently to our
>> different constraints without the cumbersome to create as many docker
>> images
>> as it was before.
>>
>
> ​Great! Nice to hear that Youcef!
>
> Thanks
> Imesh
> ​
>
>>
>> Thanks again.
>>
>> Youcef HILEM
>>
>>
>>
>> --
>> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architectur
>> e-f62919.html
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
>
> --
> *Imesh Gunaratne*
> Associate Director/Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Senior Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Collect config-docs in all featues when packaging product distribution

[Imesh Gunaratne]

On Tue, Sep 12, 2017 at 9:10 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Imesh,
>
> ​+1 Wouldn't we need to ship these files?​ Are we planning to add them to
>> the documentation?
>
> AFAIK the idea is to product team check all the relevant configs for a
> product and create a deployment.yaml manually and ship that with the
> product.
>

​Thanks for the clarification Thusitha!​

>
> Doc team is working on a project to document all the relevant configs per
> product based on the generated config files.
>
> Thanks
> Thusitha
>
> On Wed, Sep 13, 2017 at 8:00 AM, Imesh Gunaratne  wrote:
>
>> On Wed, Aug 30, 2017 at 11:07 PM, Danesh Kuruppu  wrote:
>>
>>> ​...​
>>>
>>> ├── distribution
>>>  ├── target
>>>
>>>
>>> * ├── config-docs ├── secure-vault.yaml
>>>└── wso2.carbon.yaml*
>>>  └── wso2carbon-kernel-5.2.0-SNAPSHOT.zip
>>>
>>> So when generating product distribution, we automatically get all
>>> configuration files used in the product. This will also help when creating
>>> product document.
>>>
>>
>> ​+1 Wouldn't we need to ship these files?​ Are we planning to add them to
>> the documentation?
>>
>> Thanks
>> Imesh
>>
>>
>>>
>>> Appreciate your input on this.
>>>
>>> 1. http://wso2-oxygen-tank.10903.n7.nabble.com/Carbon-C5-Server
>>> -Configuration-Model-td144549.html
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: dan...@wso2.com
>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>>> Web: WSO2 Inc 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Associate Director/Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thusitha Dayaratne
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809 <+94%2071%20275%206809>
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Collect config-docs in all featues when packaging product distribution

[Thusitha Thilina Dayaratne]

Hi Imesh,

​+1 Wouldn't we need to ship these files?​ Are we planning to add them to
> the documentation?

AFAIK the idea is to product team check all the relevant configs for a
product and create a deployment.yaml manually and ship that with the
product.

Doc team is working on a project to document all the relevant configs per
product based on the generated config files.

Thanks
Thusitha

On Wed, Sep 13, 2017 at 8:00 AM, Imesh Gunaratne  wrote:

> On Wed, Aug 30, 2017 at 11:07 PM, Danesh Kuruppu  wrote:
>
>> ​...​
>>
>> ├── distribution
>>  ├── target
>>
>>
>> * ├── config-docs ├── secure-vault.yaml
>>└── wso2.carbon.yaml*
>>  └── wso2carbon-kernel-5.2.0-SNAPSHOT.zip
>>
>> So when generating product distribution, we automatically get all
>> configuration files used in the product. This will also help when creating
>> product document.
>>
>
> ​+1 Wouldn't we need to ship these files?​ Are we planning to add them to
> the documentation?
>
> Thanks
> Imesh
>
>
>>
>> Appreciate your input on this.
>>
>> 1. http://wso2-oxygen-tank.10903.n7.nabble.com/Carbon-C5-Server
>> -Configuration-Model-td144549.html
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Associate Director/Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thusitha Dayaratne
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

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

Re: [Architecture] [C5] Collect config-docs in all featues when packaging product distribution

[Imesh Gunaratne]

On Wed, Aug 30, 2017 at 11:07 PM, Danesh Kuruppu  wrote:

> ​...​
>
> ├── distribution
>  ├── target
>
>
> * ├── config-docs ├── secure-vault.yaml
>  └── wso2.carbon.yaml*
>  └── wso2carbon-kernel-5.2.0-SNAPSHOT.zip
>
> So when generating product distribution, we automatically get all
> configuration files used in the product. This will also help when creating
> product document.
>

​+1 Wouldn't we need to ship these files?​ Are we planning to add them to
the documentation?

Thanks
Imesh


>
> Appreciate your input on this.
>
> 1. http://wso2-oxygen-tank.10903.n7.nabble.com/Carbon-C5-
> Server-Configuration-Model-td144549.html
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
Associate Director/Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Webapp server for React based webapps

[Dilan Udara Ariyaratne]

Hi Sajith,

With respect to the Structure of the web-app, My concern is actually on the
public folder because I do not think that only the stuff that lie under
public folder would be public, please correct
me If I am wrong. IMO, I believe that everything else here is also public
since this doesn't carry any server-side rendering code.

So, may be we need to reconsider restructuring stuff that currently lie
within the public folder. For example, moving everything with in the public
folder into pages, WDYT?

And, also would you explain the purpose of those extensions/device-types
content ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Sep 12, 2017 at 10:59 AM, Joseph Fonseka  wrote:

> Hi Sajith
>
> +1 For the server, would like to propose adding gzip support as well.
>
> Does the web-server enforce the web-app structure ? If so IMHO it would be
> best not to do that.
>
> Thanks & Regards
> Jo
>
>
>
>
>
>
> On Tue, Sep 12, 2017 at 10:13 AM, Chanaka Jayasena 
> wrote:
>
>> Hi Sajith,
>>
>> +1 for the web server. We will be able to replace the MS4J service inside
>> carbon-apimgt with this one when it's available.
>>
>> Following are some of my suggestions and thoughts.
>>
>> Can we put the public/images/logo.png and public/css/styles.css in the
>> default theme ?
>>
>> I believe the extensions are stand alone js files. In APIM case it will
>> be useful to add a new page to the store app. But we will have to write the
>> react app client side routing to pick the extension as a new route.
>>
>>
>> thanks,
>> Chanaka
>>
>> On Mon, Sep 11, 2017 at 3:35 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of developing $subject. Tentatively this webapp
>>> server is named as "Carbon UI Server".
>>>
>>> # Major goals of this webapp server are following:
>>>
>>>- Enforcing security measures.
>>>   - Setting proper cache headers
>>>   - Setting recommended security related HTTP headers
>>>   - Protection against file system navigation through URLs
>>>- Defining a structure for webapps.
>>>   - Requirement is to properly define places to put page(s),
>>>   themes, UI extensions, and internalization language files in the 
>>> webapp.
>>>- Proper routeing for SPA apps.
>>>   - For SPA apps, index.html should be served for any request for a
>>>   page.
>>>
>>> # Proposing directory structure:
>>>
>>> - Webapps will be placed in /wso2//d
>>> eployments/reactapps/
>>>
>>> - Structure of a webapp:
>>>
>>> 
>>> ├── configuration.yaml
>>> │
>>> ├── extensions
>>> │   ├── widgets
>>> │   │   ├── line-chart/
>>> │   │   ├── bar-chart/
>>> │   │   └── calendar/
>>> │   │   ├── bundle.js
>>> │   │   ├── styles.css
>>> │   │   └── widget.json
>>> │   │
>>> │   └── device-types
>>> │   ├── andoid/
>>> │   ├── ios/
>>> │   └── ardino/
>>> │   └── ports.json
>>> ├── i18n
>>> │   ├── fr.properties
>>> │   └── en.properties
>>> │
>>> ├── pages
>>> │   └── index.html
>>> │
>>> ├── public
>>> │   ├── images
>>> │   │   └── logo.png
>>> │   ├── css
>>> │   │   └── styles.css
>>> │   └── js
>>> │   └── bundle.js
>>> │
>>> └── themes
>>> ├── dark/
>>> └── light
>>> ├── js
>>> │   └── some.js
>>> └── css
>>> └── styles.css
>>>
>>>
>>> - configuration.yaml will contain configurations of the web app (e.g.
>>> app context path, custom security headers). These configurations should be
>>> able to add/override through the deployment.yaml file.
>>>
>>> - extensions directory contains UI extensions. There can be multiple
>>> types of extensions and they are categorized accordingly into
>>> sub-directories inside the extensions directory. Each extension should
>>> be wrapped with a directory (the name of the directory will be the name of
>>> the extension), and placed inside the relevant type. Thus, the fully
>>> qualified name of an extension will be : (e.g.
>>> widgets:line-chart)
>>>
>>> - i18n directory will bear the internalization language files.
>>>
>>> - public directory contains any client-side resources of the app.
>>>
>>> - themes directory contains the themes of the app. Each theme should be
>>> put inside a sub-directory.
>>>
>>>
>>> # URL patterns:
>>>
>>>- Pages
>>>   - /path/to/page (e.g.
>>>   https://localhost:9292/pets-store/home
>>>   )
>>>- Resources of the app
>>>   - /public/app/
>>>   (e.g. https://localhost:9292/pets-store/public/app/images/logo.png
>>>   )
>>>   - Resources of an extension
>>>   - 
>>> /public/extensions///
>>>   (e.g. 

Re: [Architecture] [APIM] Threat Protection for API Manager

[Gayan Chamara]

Hi,
I've been testing the initial implementation of Threat Protection system
for fast several days. In initial testings following statistics were
collected.

XML Performance ​Results

JSON Performance Results

As per above graphs, It was clear that in XML Threat Protection System,

   - Analyzer object instantiation time is much higher
   - Creating XML Factory object is also costly operation

Similarly in JSON Threat Protection System,

   - Analyzer object instantiation time is higher compared to other
   activities


*Solutions Identified*

   - Both json and xml object instantiation phase involves reading
   configurations via  ServiceReferenceHolder. So it was decided to cache the
   configuration data for fast access.
   - In addition to that, JSON threat protection mechanism was changed from
   Schema based validation mechanism to JSON Stream parsing mechanism for
   better performance.

After the modifications made to the system, following results were obtained,

XML Performance Results


JSON performance Results

As it seems that XML System still has some performance issue. And I'll keep
exploring areas where I can improve the performance and In the meantime
your valuable ideas regarding the project are more than welcome.

Thanks.
Gayan.

On Mon, Jul 31, 2017 at 10:48 AM, Gayan Chamara  wrote:

> Hi All,
>
> I’m working on a Threat Protection system for API Manager. The system will
> responsible for detecting and preventing of xml and json based attacks on
> API Manager gateway.
>
> How did APIM supported this so far?
>
> So far APIM users used custom mediators and handlers to handle this type
> of requirements.
>
> Some of our users are using JSON, XML payload validation with the help of
> handlers. But those are never shipped as first class features.  Also they
> were using new throttling feature to implement IP whitelisting policies,
> header/query parameter based filtering etc.
>
> What is next?
>
> When APIM moving ahead with ballerina based gateway, we will ship some of
> these common threat detection mechanisms as OOB features.
>
> Initial plan is to let users to plug threat detection policy in two
> different levels as follows.
>
> 01. Global threat protection policy
>
> System administrator can use predefined policy set with specific
> configurations.
>
> 02. Per API threat protection policy
>
> We need to allow users to add threat protection policy in API level with
> specific parameters. For example one API may expect 100 sub-elements in
> JSON payload while other API will allow only 10 sub elements in JSON
> payload. These protection policies may depend on the API.
>
>
> Initial List of Threats Identified
>
>-
>
>XML Bombs
>-
>
>Canonicalization attacks
>-
>
>Coercive Parsing (json/xml)
>-
>
>XML External Entity Attacks
>-
>
>SQL Injection
>-
>
>Schema Poisoning (json/xml)
>-
>
>Buffer overflows
>-
>
>TCP/IP Based Attacks
>-
>
>   IP Address Spoofing
>   -
>
>   TCP Sequence Number Prediction
>   -
>
>   Port Scanning
>   -
>
>WSDL Scanning
>-
>
>XML Routing Detours
>-
>
>Network Eavesdropping
>-
>
>Cross-site scripting
>-
>
>Denial of Service (DoS) attacks
>-
>
>Parameter Tampering
>-
>
>   HTTP Header Manipulation
>   -
>
>   Form Field Manipulation
>   -
>
>   Query string manipulation
>
>
> List of Solutions Identified
>
>-
>
>Limiting the depth of xml and json
>-
>
>Limiting the length of elements
>-
>
>Limiting count of elements and number of items in json arrays
>-
>
>Disabling external/embedded DTD parsing
>-
>
>Disabling embedded schemas
>-
>
>Disabling loading schemas from unauthorized locations
>-
>
>Set correct permissions to local schema files (disallow write access)
>-
>
>IP whitelisting/blacklisting
>-
>
>Rate Limiting
>-
>
>Escaping All User Supplied Input
>
>
>
> Design Details
>
> Number of User Interfaces is going to be added to the API Manager as admin
> users should have a way to enable/disable/create threat protection policies.
>
> Threat protection system can be implemented as a Global level (which is
> going to monitor all the API requests) mechanism or Per API mechanism
> (Which will be applicable for specified APIs) mechanism. Whether the
> initial implementation should be Global or per API, should be discussed.
>
> In addition to that, set of threats should be identified for initial
> implementation of the system.  Any other ideas or suggestions are also
> welcome.
>
> PS: A detailed document about Threats on Web Services is attached below.
>
>
>
> Thanks & Regards,
>
> *Gayan Chamara*
>
> *Software Engineering Intern*
> *WSO2*
>
>
> *Email: gaya...@wso2.com  *
>
> *Mobile : +94 71 7285827 <+94%2077%20767%201807>*
>
> 
>



-- 
Regards,

*Gayan Chamara*

Re: [Architecture] [APIM] Supporting Thrift protocol for GW-KM communication with Load Balancing

[Imesh Gunaratne]

I had an offline discussion with Suho on supporting TCP load balancing for
Thrift.

As we see we can simply achieve it by updating the DataBridge component and
initiating a new session when the load balancer switches a TCP connection
from one backend Thrift node to another. We might not need to replicate the
sessions.

Thanks
Imesh

On Fri, Sep 1, 2017 at 12:25 AM, Asela Pathberiya  wrote:

> Hi APIM team,
>
> According to the docs; We are not recommending the thrift protocol to
> communicate with GW and KM when even TCP load balancer is used.
>
> The problem is that;  thrift connection must be authenticated & thrift
> session is not replicated among key manager nodes.
>
> IMO; we have three solution for this.
>
> 1.  Replicate thrift session in KM nodes
>
> 2.  Client side load balancing
>
> 3. Sending authentication credentials from GW to KM in every request.
> This has been implemented in WSO2IS for XACML PDP.  You can find the
> details [1] & sample thrift client [2]
>
> We can easily implement approach 3,  Shall we consider this for next APIM
> release ?
>
> [1] http://xacmlinfo.org/2014/04/11/thrift-load-balancing/
> [2] https://svn.wso2.org/repos/wso2/people/asela/xacml/pep/thrift-LB
>
> Thanks,
> Asela.
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
*Imesh Gunaratne*
Associate Director/Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Kubernetes ConfigMaps for Managing Product Configurations

[Imesh Gunaratne]

On Sun, Sep 10, 2017 at 9:54 AM, Youcef HILEM 
wrote:

> Hi All,
>
> Thank you all.
> A PR has just been submitted
> (https://github.com/wso2/kubernetes-apim/pull/27).
> I will be able to start testing on openshift 3.4.
> With this flexibility I can really adapt easily and efficiently to our
> different constraints without the cumbersome to create as many docker
> images
> as it was before.
>

​Great! Nice to hear that Youcef!

Thanks
Imesh
​

>
> Thanks again.
>
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architectur
> e-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
*Imesh Gunaratne*
Associate Director/Architect
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture