Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Frank Leymann]

Hi Varuni,

thanks a lot!  Do read it correct that HTTP2 has worse response time than
HTTP?  Although many people claim the opposite...

Best regards,
Frank




Am Sa., 12. Jan. 2019 um 03:55 Uhr schrieb Varuni Punchihewa <
varu...@wso2.com>:

> Hi Frank,
>
> Here the server is written in Ballerina and you can find the Ballerina
> performance summary in,
> [1]
> https://github.com/ballerina-platform/ballerina-lang/blob/master/performance/benchmarks/summary.md
>
> Best Regards,
>
> *Varuni Punchihewa*
> Software Engineer - Intern | *WSO2*
> *Tel:* +94 71 699 5861
> 
>
>
> On Fri, Dec 21, 2018 at 4:59 PM Frank Leymann  wrote:
>
>> +1 - I am eager to see this :-)
>>
>> Are we running a performance comparison between HTTP 1.1 and HTTP/2?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 21. Dez. 2018 um 05:25 Uhr schrieb Nuwan Dias :
>>
>>>
>>>
>>> On Thu, Dec 20, 2018 at 5:10 PM Sanjeewa Malalgoda 
>>> wrote:
>>>
 Can you create document explaining this feature in detail with possible
 user scenarios. It would be great if we can have some test artifacts as
 well.

>>>
>>> +1. Let's create a GDoc and share please.
>>>

 Thanks,
 sanjeewa.

 On Thu, Dec 20, 2018 at 3:38 PM Varuni Punchihewa 
 wrote:

> Hi Sanjeewa,
>
> There's no effect to ballerina filters from setting the http version
> to 2.0. But the connection established via the client and the microgateway
> and microgateway with the backend would be more efficient and fast due to
> the features like header compression, it's full multiplexed nature etc.
> Furthermore, we won't be using the server push feature in the microgateway
> since there's no much use cases of it with the microgateway.
>
> Thank you
> Best Regards,
>
> *Varuni Punchihewa*
> Intern - Software Engineering | *WSO2*
> *Tel:* +94 71 699 5861
> 
>
>
> On Fri, Oct 26, 2018 at 12:05 PM Sanjeewa Malalgoda 
> wrote:
>
>> Can you please explain how are we planning to go ahead with this
>> feature? Even now with ballerina we can create http2 client endpoint or
>> server endpoint with http2 follows.
>> If we do same now how will it work with existing filters?
>>
>> endpoint http:Listener testEP {
>> port: 9095,
>> httpVersion: "2.0"
>> };
>>
>> Thanks,
>> sanjeewa.
>>
>> On Sat, Oct 6, 2018 at 5:13 PM Varuni Punchihewa 
>> wrote:
>>
>>> Hi all!
>>> Please find my project description and the design as below.
>>>
>>> *Project description*
>>>
>>> The WSO2 API Microgateway currently supports only http and https as
>>> the incoming and outgoing transport protocols. This project is for 
>>> enabling
>>> it to support HTTP2 for both incoming and outgoing message flows. We 
>>> need
>>> to evaluate the use of OAuth2.0, and rate limiting capabilities on the
>>> current Microgateway and see how this impacts the move to HTTP2.
>>>
>>> *Solution Design*
>>>
>>>- Supporting the messages received by the microgateway from the
>>>clients, by both HTTP/1.1 and HTTP/2.0 protocols
>>>- All the communication that happen between the Microgateway and
>>>the Back end service will support HTTP/2.0 (The maximum version 
>>> supported
>>>is set to 2.0. In case if it supports only 1.1, then it will be 
>>> backward
>>>compatible to 1.1 and would not be a problem to communications)
>>>
>>> Best Regards,
>>>
>>> *Varuni Punchihewa*
>>> Intern - Software Engineering | *WSO2*
>>>
>>> *Tel:* +94 71 699 5861
>>> ___
>>> 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
>>
>

 --
 *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

>>>
>>>
>>> --
>>> *Nuwan Dias* | Director | WSO2 Inc.
>>> (m) +94 777 775 

Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Varuni Punchihewa]

Hi Frank,

Here the server is written in Ballerina and you can find the Ballerina
performance summary in,
[1]
https://github.com/ballerina-platform/ballerina-lang/blob/master/performance/benchmarks/summary.md

Best Regards,

*Varuni Punchihewa*
Software Engineer - Intern | *WSO2*
*Tel:* +94 71 699 5861



On Fri, Dec 21, 2018 at 4:59 PM Frank Leymann  wrote:

> +1 - I am eager to see this :-)
>
> Are we running a performance comparison between HTTP 1.1 and HTTP/2?
>
> Best regards,
> Frank
>
>
>
>
> Am Fr., 21. Dez. 2018 um 05:25 Uhr schrieb Nuwan Dias :
>
>>
>>
>> On Thu, Dec 20, 2018 at 5:10 PM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Can you create document explaining this feature in detail with possible
>>> user scenarios. It would be great if we can have some test artifacts as
>>> well.
>>>
>>
>> +1. Let's create a GDoc and share please.
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, Dec 20, 2018 at 3:38 PM Varuni Punchihewa 
>>> wrote:
>>>
 Hi Sanjeewa,

 There's no effect to ballerina filters from setting the http version to
 2.0. But the connection established via the client and the microgateway and
 microgateway with the backend would be more efficient and fast due to the
 features like header compression, it's full multiplexed nature etc.
 Furthermore, we won't be using the server push feature in the microgateway
 since there's no much use cases of it with the microgateway.

 Thank you
 Best Regards,

 *Varuni Punchihewa*
 Intern - Software Engineering | *WSO2*
 *Tel:* +94 71 699 5861
 


 On Fri, Oct 26, 2018 at 12:05 PM Sanjeewa Malalgoda 
 wrote:

> Can you please explain how are we planning to go ahead with this
> feature? Even now with ballerina we can create http2 client endpoint or
> server endpoint with http2 follows.
> If we do same now how will it work with existing filters?
>
> endpoint http:Listener testEP {
> port: 9095,
> httpVersion: "2.0"
> };
>
> Thanks,
> sanjeewa.
>
> On Sat, Oct 6, 2018 at 5:13 PM Varuni Punchihewa 
> wrote:
>
>> Hi all!
>> Please find my project description and the design as below.
>>
>> *Project description*
>>
>> The WSO2 API Microgateway currently supports only http and https as
>> the incoming and outgoing transport protocols. This project is for 
>> enabling
>> it to support HTTP2 for both incoming and outgoing message flows. We need
>> to evaluate the use of OAuth2.0, and rate limiting capabilities on the
>> current Microgateway and see how this impacts the move to HTTP2.
>>
>> *Solution Design*
>>
>>- Supporting the messages received by the microgateway from the
>>clients, by both HTTP/1.1 and HTTP/2.0 protocols
>>- All the communication that happen between the Microgateway and
>>the Back end service will support HTTP/2.0 (The maximum version 
>> supported
>>is set to 2.0. In case if it supports only 1.1, then it will be 
>> backward
>>compatible to 1.1 and would not be a problem to communications)
>>
>> Best Regards,
>>
>> *Varuni Punchihewa*
>> Intern - Software Engineering | *WSO2*
>>
>> *Tel:* +94 71 699 5861
>> ___
>> 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
>

>>>
>>> --
>>> *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
>>>
>>
>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>

[Architecture] [Announce] [Dev] WSO2 Product Installation Resources Released!

[Chiranga Alwis]

WSO2 Installation Experience team is pleased to announce the release of
Docker and Docker Compose resources for WSO2 products.

*Docker*
Released artifacts:

   - WSO2 API Manager v2.6.0.2 -
   https://github.com/wso2/docker-apim/releases/tag/v2.6.0.2
   - WSO2 Enterprise Integrator v6.4.0.2 -
   https://github.com/wso2/docker-ei/releases/tag/v6.4.0.2
   - WSO2 Identity Server v5.7.0.2 -
   https://github.com/wso2/docker-is/releases/tag/v5.7.0.2
   - WSO2 Stream Processor v4.3.0.2 -
   https://github.com/wso2/docker-sp/releases/tag/v4.3.0.2

Issues:

   - WSO2 API Manager - https://github.com/wso2/docker-apim/issues
   - WSO2 Enterprise Integrator - https://github.com/wso2/docker-ei/issues
   - WSO2 Identity Server - https://github.com/wso2/docker-is/issues
   - WSO2 Stream Processor - https://github.com/wso2/docker-sp/issues


*How You Can Contribute*
Join our mailing list and correspond with the developers directly.

Developer List: d...@wso2.org
User List: u...@wso2.org

*Reporting Issues*
We encourage you to report issues and documentation faults regarding WSO2
product Docker and Docker Compose resources through respective repositories
by creating issues.

Thank you!
WSO2 Installation Experience Team

-- 
Yours sincerely,

*Chiranga Alwis*
Software Engineer | WSO2

*Mobile : *+94775930497
*Email: *chirangaal...@gmail.com
*LinkedIn: *https://lk.linkedin.com/in/chiranga-alwis-391342a9
*Medium:* https://medium.com/@chirangaalwis


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

Re: [Architecture] Cookie Based Authentication for Micro-gateway.

[Ishara Cooray]

Hi Chamindu,
Couple of questions came to my mind is

1. What will be the case if both headers are provided? Are we doing both
validations?
2. Do we have a expiry time for this cookie.
3.In the case of invalid cookie how can one obtain a new valid cookie?


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Fri, Jan 4, 2019 at 5:04 PM Chamindu Udakara  wrote:

> Hi All,
>
> My project is to add cookie based authentication for micro-gateway. This
> is the approach that I have come up with. Please review and let me know
> what you think and please be kind enough to suggest your suggestions.
>
> Requirement
>
> Provide authentication for product micro-gateway with cookie based
> authentication which uses session HTTP cookies for authentication.
>
> Suggested Approach
>
> When an user invoke an API with a cookie, micro-gateway has to validate
> that cookie prior to the response. The list of cookies included in the HTTP
> request which use to authenticate, have to be extracted from the request.
> From all extracted cookies,their respective session ID value has to be
> extracted properly.
>
> The Authn filter will check incoming request to micro-gateway and
> determine whether it contains header as "Authorization" or header as
> "Cookie". If header is equals to "Cookie" then the cookie validation
> process will be executed and cookie will be validated. If not it will
> execute as a normal request which contains header as "Authorization". The
> session ID of the required cookie can be provided to server as a direct key
> value pair at the micro-gateway server startup.
>
>
>
>
>
>
> if (request.hasHeader(authHeaderName)) {
>
>authHeader = request.getHeader(authHeaderName);
>
>}else if (request.hasHeader(COOKIE_HEADER)){
>
>//Authentiction with HTTP cookies
>
>CookieBasedAuth cookieBasedAuth = new CookieBasedAuth ();
>
>result = cookieBasedAuth.processRequest(listener, request,
> context);
>
>}else {
>
>log:printError("No authorization header was provided");
>
>setErrorMessageToFilterContext(context,
> API_AUTH_MISSING_CREDENTIALS);
>
>sendErrorResponse(listener, request, untaint context);
>
>return false;
>
>}
>
> Above code segment will do that identification of header type of the
> coming request. Then the validation process will be done at the separate
> file named as* "cookie.bal"*. In this file the extraction of session Id
> and validation of that Id with given value at the server startup will be
> done. For that I have implemented a new function as "*ProcessRequest*"
> which returns a string or an error. If any of the cookies included in
> request is not equal to given Id then the validation process will be
> failed. If it fails, then it throws an error and authnFilter will be
> failed. If any of session Id of a cookie matches with given one then that
> id will be returned to authnFilter for further execution at authnFilter.
>
> public function processRequest(http:Listener listener, http:Request
> request, http:FilterContext context)
>
>returns string|error {
>
>boolean isAuthorized;
>
>//get required cookie as config value
>
>string requiredCookie = config:getAsString(COOKIE_HEADER, default
> = "");
>
>//extraxt cookies from the incoming request
>
>string authHead = request.getHeader(COOKIE_HEADER);
>
>string[] cookies = authHead.trim().split(";");
>
>foreach cookie in cookies{
>
>io:println(cookie);
>
>string[] sessionIds = cookie.trim().split("=");
>
>string sessionId = sessionIds[1];
>
>if (sessionId == requiredCookie){
>
>return sessionId;
>
>}
>
>}
>
>error notFound = {message:"No matched cookie found"};
>
>return notFound;
>
> }
>
>
>
> *Chamindu Udakara *
> *Software engineering Intern*
> WSO2  (University of Moratuwa)
> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] API Manager integration with Istio

[Sanjeewa Malalgoda]

Hi All,
The intention of this mail is to discuss about API Manager istio
integration and come to conclusion on design and architecture. With this
particular feature our target group is users who already use API Management
and have requirement to move towards service mesh architecture. We believe
this will help us to prove our capability to integrate with service mesh
architecture. This feature will allow users to expose their services
deployed on service mesh as APIs and apply different QoS. Here is a brief
overview on what we are planning to do.


*Overview of the feature*

   - When users move towards microservice architecture from monolithic app
   architecture we will have thousands of microservices. When we break each
   monolith app to microservices it will create more services.
   - So managing all these microservices would be a challenge.
   - Istio helps to reduce the complexity of this type of deployments. It
   is a platform, including APIs that let it integrate into any logging
   platform, or telemetry or policy system.
   - Istio creates a “service mesh” that routes traffic between
   interrelated services in a secure and robust way so that the developers of
   each individual service can focus on what a service does rather than the
   details of how it communicates.
   - However when users need to expose these microservices services to
   outside in a secured controlled manner we need API Management.
   - Most of the time we need to create APIs(for microservices) and share
   them with other developers who might be part of your organization or who
   might be external.
   - So API Management within service mesh solution is required to operate
   successfully. With this capability, user can expose one or more services
   from an Istio mesh as APIs by adding API management capabilities.


*Approach*When it comes to enabling API Management for service mesh there
are multiple approaches we can follow. One way is use the mixer plugin
model, which is a standard extension point available in Istio. We believe
this is most suitable way of integrating API Management with istio.

*Mixer* is a core Istio component which runs in the control plane of the
service mesh. Mixer's plugin model enables new rules and policies to be
added to groups of services in the mesh without modifying the individual
services or the nodes where they run. API management policies
authentication (by API key validation), throttling, etc can be deployed and
managed at API Manager side without doing any changes to the actual
microservice or sidecar proxy each time deployment happens. Following
diagrams will explain how the mixer plugin captures telemetry and performs
the policy check.

Whenever user deploys a service, Istio injects a sidecar to the particular
service as a proxy. For each request sent to the service, the sidecar proxy
will capture a set of data and publish it to the Mixer. If the user needs
to expose this service to outside in a managed way, an API should be
created in API Manager. This can be done via different methods:

   - Automated process - When a user deploys a service which is required to
   be exposed, an API will be created in API Manager automatically.
   - Manual process - Once a service is deployed, the user can go to the
   API Manager developer portal and create API by giving service data and
   swagger file.

*Route of a Successful Request*


   1. The client sends the request to the service (Istio capture the
   request and redirect to the istio-proxy). This enters the Kubernetes
   cluster via an ingress point.
   2. Proxy captures attributes and sends to the Mixer as attributes.
   3. Mixer adapter does the throttling, authentication parts and calls for
   the API Manager Deployment.
   4. API Manager Deployment captures the request and sends the relevant
   response to the mixer.
   5. Mixer makes the policy decisions and sends back to the istio-proxy.
   6. The proxy delivers the request to the microservice.
   7. Microservice executes the service logic and sends the response
   8. The response is sent out to the client

API Manager team started initial work on this project and we will work on
features in phased approach. First we will do introspection call which
validates access token. Then we can think of throttling, usage data
monitoring etc. We will create repo named
istio-apim and start our work there. If you have any suggestions to above
proposal please let us know.

Thanks,
sanjeewa.
-- 
*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