Hi Saneth, Thanks for your views. One important reason to implement this is that this feature has been requested, so that the above mentioned requirements can be met.
Thanks, Viduranga. On Tue, Dec 12, 2017 at 11:10 AM, Saneth Dharmakeerthi <[email protected]> wrote: > Hi Viduranga, > > Sorry for late reply, please find my view bellow > > i) In a scenario where both the back end and the API-M requests > authorization tokens. > > If the back end already expects an authorization token by the name > "Authorization", then there will be a complication when sending two tokens > by the same name; one for the back end and he other for APIM. So the > authorization header name of APIM should be changed. > > In this type of a scenario, both the API-M and the back end requires > authorization tokens and the header field would be "Authorization" for > both. This would make a confusion and also since API-M provides a > configuration to stop the authorization header from being sent to the back > end (RemoveOAuthheadersFromOutMessage) then if that config is set to > true, then the value that comes under the header field "Authorization" > would not get transferred to the back end. > > > Here I also agreed with Kishanthan, IMO changing the header name is seems > to be out of spec, So main issue here is both parties client -> APIM and > APIM-> Backend need to communicate with header "Authorization", > So cant we keep the header option "Authorization" in-between client->APIM > as it is and we can pass some other header like "Back-End-Authorization" > in addition to "Authorization" header. So in APIM, it will do the > authorization > using "Authorization" header and then switch the "Back-End-Authorization > " to "Authorization" and send it backend. So both client -> APIM and > APIM-> Backend will do their authorization using "Authorization" header. > Even if back-end required the token in some other format we can sitch it to > the required type, but IMO we need to keep the "Authorization" header > between Client->APIM as it is. > > ii) Existing client apps that communicate with a back end with > authorization tokens such as "TOKEN", "KEY". > > When APIM is introduced to an existing system where client apps used to > communicate with the back end with their own authorization tokens such as > "TOKEN", "KEY" etc. , the client apps will have to be modified to send > "Authorization" instead. This can be avoided with customizing the > authorization header. > > I do not agree with here. Client app and Backend may communicate with > some other token but, After introducing APIM they cant use the same token > to communicate with APIM. If they can use the same token I don't see any > point introducing APIM between them. Even you keep the header as it is > like "TOKEN", "KEY", the token generation part need to implement in the > client side according to APIM or even hard cored the client credential > token in the clinet side. SO anyhow client modification is there. > iii) In the APIM cloud, each tenant will be able to define their own > authorization header field. > > Also, this implementation, by default already supports the prevailing > "Authorization" header field. So, if a client doesn't do any > configurations, he/she can use the system without any issue as before. If a > client wants to configure custom header field ti support any scenario, he > will have to make the necessary configurations. > > This may be a valid requirement but I have doubt there is an available > option to change the header name other than "*Authorization*" according > to spec [1][2] > > [1] https://tools.ietf.org/html/rfc6749#section-4.1.1 > [2] https://tools.ietf.org/html/rfc6750#section-2.1 > > > Thanks and Best Regards, > > Saneth Dharmakeerthi > *Associate Technical Lead* > WSO2, Inc. > Mobile: +94772325511 <+94%2077%20232%205511> > > <http://wso2.com/signature> > > On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[email protected]> > wrote: > >> Hi, >> >> This is a quick update to the current implementation of this feature. >> >> Image 1 & 2 shows how the "CustomOAuth2header" and the >> "RemoveHeadersFromOutMessage" configs are setup in the tenant-conf.xml and >> the api-manager.xml. The custom header config in the api-manager.xml is a >> global configuration and it will only be applied if there is no config >> available in the tenant-conf.json (per tenant config). And if both configs >> in tenant-conf.json and the api-manager.xml are not available, then the >> "Authorization" header would work. >> >> Image 3 shows how the "API Console" in the APIM Store looks like once the >> custom header fields are configured. This header will change based on the >> tenant of the API. >> >> *Note:* However a complication occurred with this implementation. The >> web browser will not allow the custom header to be passed along with the >> request. Hence the custom header has to be added to the list of allowed >> headers. >> >> In addition to that, it was discussed to improve this feature to have >> custom OAuth header at the API level. Hence an API creator has the >> capability to create custom OAuth2 headers specific to each API. >> >> The current design for this improvement is to add another field to the >> "api.rxt" there by adding another field to the API model, so that the API >> creator can set a custom OAuth2 header while creating an API in the API-M >> Publisher. >> >> Once the API is published, this custom OAuth2 header will be saved to the >> registry under the API and will be deployed to the Gateway through the >> synapse-config. >> ============================================================ >> =============== >> Image 1: >> tenant-conf.json >> [image: Inline image 1] >> ============================================================ >> =============== >> Image 2: >> api-manager.xml >> [image: Inline image 3] >> ============================================================ >> =============== >> Image 3: >> API-M Store >> >> >> ============================================================ >> =============== >> >> Any ideas and suggestions are highly appreciated! >> >> Thanks, >> Viduranga. >> >> On Thu, Dec 7, 2017 at 8:59 AM, Viduranga Gunarathne <[email protected]> >> wrote: >> >>> Hi Kishanthan. >>> >>> The use cases for this are as follows: >>> >>> i) In a scenario where both the back end and the API-M requests >>> authorization tokens. >>> >>> If the back end already expects an authorization token by the name >>> "Authorization", then there will be a complication when sending two tokens >>> by the same name; one for the back end and he other for APIM. So the >>> authorization header name of APIM should be changed. >>> >>> In this type of a scenario, both the API-M and the back end requires >>> authorization tokens and the header field would be "Authorization" for >>> both. This would make a confusion and also since API-M provides a >>> configuration to stop the authorization header from being sent to the back >>> end (RemoveOAuthheadersFromOutMessage) then if that config is set to >>> true, then the value that comes under the header field "Authorization" >>> would not get transferred to the back end. >>> >>> >>> ii) Existing client apps that communicate with a back end with >>> authorization tokens such as "TOKEN", "KEY". >>> >>> When APIM is introduced to an existing system where client apps used to >>> communicate with the back end with their own authorization tokens such as >>> "TOKEN", "KEY" etc. , the client apps will have to be modified to send >>> "Authorization" instead. This can be avoided with customizing the >>> authorization header. >>> >>> >>> iii) In the APIM cloud, each tenant will be able to define their own >>> authorization header field. >>> >>> Also this implementation, by default already supports the prevailing >>> "Authorization" header field. So, if a client doesn't do any >>> configurations, he/she can use the system without any issue as before. If a >>> client wants to configure custom header field ti support any scenario, he >>> will have to make the necessary configurations. >>> >>> Thanks, >>> Viduranga. >>> >>> On Tue, Dec 5, 2017 at 3:48 PM, Kishanthan Thangarajah < >>> [email protected]> wrote: >>> >>>> The header name "Authorization" is what commonly used by all the >>>> clients/proxies. So we defining our own way for the "header name" is what >>>> my concern is. If we define such customized name, will the external clients >>>> adhere to that? >>>> >>>> The spec says that the common format used is Authorization = >>>> <credentials> [1] >>>> >>>> So shouldn't we use a customized way or scheme for the <credentials> >>>> part only, to identify tenant specific tokens (which is the requirement for >>>> $subject), but not change the header name itself? >>>> >>>> Some discussions related to this in SO - >>>> https://stackoverflow.com/questions/42574022/custom-authoriz >>>> ation-header >>>> https://stackoverflow.com/questions/8463809/customize-the-au >>>> thorization-http-header >>>> >>>> Thanks, >>>> [1] https://tools.ietf.org/html/rfc7235#section-4.2 >>>> >>>> On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[email protected]> >>>> wrote: >>>> >>>>> "The OAuth 2.0 Authorization Framework: Bearer Token Usage" spec [1] >>>>> mentions 3 ways the token could be sent to the Resource Server - APIM >>>>> Gateway in this case: >>>>> >>>>> - Authorization Request Header Field >>>>> - Form-Encoded Body Parameter >>>>> - URI Query Parameter >>>>> >>>>> It doesn't seem to mandate that other header names couldn't be used. >>>>> Since we anyway use the recommended "Authorization" header by default, I >>>>> don't see a problem in this. >>>>> >>>>> [1] https://tools.ietf.org/html/rfc6750#page-4 >>>>> >>>>> On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> Is this approach (custom authorization header field) allowed at >>>>>> OAuth2 spec level? I mean, is this something we can customize/define and >>>>>> use it for our own, and also in accordance with the spec? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> On Thu, Nov 30, 2017 at 10:57 AM, Viduranga Gunarathne < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> @Prasanna, >>>>>>> No we do not need to restart the server. Since this configuration is >>>>>>> shipped with the tenant-conf.json, it will be automatically added to >>>>>>> each >>>>>>> of the created tenant configs in the registry, whenever a new tenant is >>>>>>> created. Even for an existing tenant it can be added manually to the >>>>>>> respective tenant config from the registry. A tenant only has to change >>>>>>> the >>>>>>> config in the registry to change the header name and save it back to >>>>>>> registry. So when a new API is published, the custom header name will be >>>>>>> read from the specific tenant config in the registry and added to the >>>>>>> synapse config so that it will be deployed in the Gateway. >>>>>>> >>>>>>> @Chamalee, >>>>>>> Yes, it will allow us to pass a custom header field instead of >>>>>>> "Authorization" to the back end for authorization. And since this >>>>>>> config is >>>>>>> deployed in the gateway through the synapse config, once a request is >>>>>>> received it can check for the specific header field for the >>>>>>> authorization >>>>>>> token. >>>>>>> >>>>>>> The use cases for this are as follows: >>>>>>> >>>>>>> i) In a scenario where both the back end and the API-M requests >>>>>>> authorization tokens. >>>>>>> If the back end already expects an authorization token by the name >>>>>>> "Authorization", then there will be a complication when sending two >>>>>>> tokens >>>>>>> by the same name; one for the back end and he other for APIM. So the >>>>>>> authorization header name of APIM should be changed. >>>>>>> >>>>>>> ii) Existing client apps that communicate with a back end with >>>>>>> authorization tokens such as "TOKEN", "KEY". >>>>>>> When APIM is introduced to an existing system where client apps used >>>>>>> to communicate with the back end with their own authorizations tokens >>>>>>> such >>>>>>> as "TOKEN", "KEY" etc. , the client apps will have to be modified to >>>>>>> send >>>>>>> "Authorization" instead. This can be avoided with customizing the >>>>>>> authorization header. >>>>>>> >>>>>>> iii) In the APIM cloud, each tenant will be able to define their own >>>>>>> authorization header field. >>>>>>> >>>>>>> Thanks, >>>>>>> Viduranga. >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 10:21 PM, Chamalee De Silva < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Viduranga, >>>>>>>> >>>>>>>> As per this design, >>>>>>>> Assuming that for all tenants the tenant-config is having the >>>>>>>> CustomAuthHeader value and RemoveOAuthHeadersFromOutMessage is >>>>>>>> configured as false, >>>>>>>> it allows us to pass a custom header field instead of Authorization >>>>>>>> header to the backend for the authorization. >>>>>>>> >>>>>>>> Can you elaborate more on what is expected by sending a custom >>>>>>>> Header field and how can we guarantee that the HTTP proxies will >>>>>>>> understand >>>>>>>> these Custom Headers ? >>>>>>>> >>>>>>>> And also, what is the real use case of differentiating this custom >>>>>>>> Header by tenant domain ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Chamalee >>>>>>>> >>>>>>>> On Mon, Nov 27, 2017 at 5:47 PM, Prasanna Dangalla < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> HI Viduranga, >>>>>>>>> >>>>>>>>> Do we need to do a restart after we add this configuration? Hope >>>>>>>>> not since we will need to restart for each every tenant and it will >>>>>>>>> be an >>>>>>>>> issue in a multi-tenant environment. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Prasanna >>>>>>>>> >>>>>>>>> On Mon, Nov 27, 2017 at 2:36 PM, Chamin Dias <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Viduranga, >>>>>>>>>> >>>>>>>>>> Small clarification, does this have any impact for caching >>>>>>>>>> <https://docs.wso2.com/display/AM210/Configuring+Caching>? >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dinusha, >>>>>>>>>>> >>>>>>>>>>> No we do not have to add it manually. "CustomOAuth2Header" >>>>>>>>>>> configuration is added to the "tenant-conf.json" that is shipped >>>>>>>>>>> with the >>>>>>>>>>> product. Therefore once a tenant is created, this config will be >>>>>>>>>>> automatically added to the registry of the specific tenant. If a >>>>>>>>>>> tenant >>>>>>>>>>> wants to change the header, then that tenant can change it in the >>>>>>>>>>> respective tenant configuration and save it to the registry. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Viduranga. >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 27, 2017 at 12:08 PM, Dinusha Dissanayake < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Viduranga, >>>>>>>>>>>> >>>>>>>>>>>> Just to make it clarify, do we have to enter CustomOAuth2Header >>>>>>>>>>>> field manually after creating a tenant or will it be automatically >>>>>>>>>>>> added >>>>>>>>>>>> when we create a tenant? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> DinushaD. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 27, 2017 at 11:41 AM, Viduranga Gunarathne < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Attached below is a sample tenant-conf.json and synapse config >>>>>>>>>>>>> featuring the proposed implementation. >>>>>>>>>>>>> >>>>>>>>>>>>> Config in tenant-conf.json >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>> ---------------- >>>>>>>>>>>>> >>>>>>>>>>>>> { >>>>>>>>>>>>> ... >>>>>>>>>>>>> "CustomOAuth2Header" : "ENG_Auth", >>>>>>>>>>>>> >>>>>>>>>>>>> "RemoveOAuthHeadersFromOutMessage" : true >>>>>>>>>>>>> ... >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Config injected into synapse config file: >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>> ---------------- >>>>>>>>>>>>> >>>>>>>>>>>>> <handlers> >>>>>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> <handler class="org.wso2.carbon.apimgt. >>>>>>>>>>>>> gateway.handlers.security.APIAuthenticationHandler"> >>>>>>>>>>>>> >>>>>>>>>>>>> <property name="customOAuthHeader" value="ENG_Auth"/> >>>>>>>>>>>>> >>>>>>>>>>>>> <property name="RemoveOAuthHeadersFromOutMessage" value="true" >>>>>>>>>>>>> /> >>>>>>>>>>>>> >>>>>>>>>>>>> </handler> >>>>>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> </handlers> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Viduranga. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> This design looks good. Please send a sample of the synapse >>>>>>>>>>>>>> config (only the portion that gets modified) so that users get a >>>>>>>>>>>>>> good >>>>>>>>>>>>>> picture of how this is supposed to be injected to the Gateway >>>>>>>>>>>>>> handler. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Nov 27, 2017 at 10:43 AM, Viduranga Gunarathne < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> APIs in APIM 2.1.0 are secured with OAuth2 access tokens. In >>>>>>>>>>>>>>> order to access an API, the consumers should generate an access >>>>>>>>>>>>>>> token and >>>>>>>>>>>>>>> the particular request should contain the generated token as an >>>>>>>>>>>>>>> HTTP header. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Eg: "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a"* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Problems:* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> i) As per the current implementation of API-M 2.1.0 the >>>>>>>>>>>>>>> structure of the access token is as above and the header field >>>>>>>>>>>>>>> is hard >>>>>>>>>>>>>>> coded to be *"Authorization"*. When the Gateway receives a >>>>>>>>>>>>>>> request to access a resource, it looks for the access token by >>>>>>>>>>>>>>> referring to >>>>>>>>>>>>>>> the header field "Authorization". The proposed >>>>>>>>>>>>>>> implementation is >>>>>>>>>>>>>>> to give each and every tenant in the system, the capability to >>>>>>>>>>>>>>> have a, "per >>>>>>>>>>>>>>> tenant" based customized authorization header field. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Eg: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tenant 1 : hr.lk --> "HR_Auth : Bearer >>>>>>>>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tenant 2 : eng.lk --> "ENG_Auth : Bearer >>>>>>>>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NB: This feature also supports the current implementation >>>>>>>>>>>>>>> of "Authorization" as the header field, so that it doesn't >>>>>>>>>>>>>>> affect the >>>>>>>>>>>>>>> existing API-Ms in production. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ii) In API-M 2.1.0 there is a feature to restrict the access >>>>>>>>>>>>>>> token, that is being sent in the request, to be passed through >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> production endpoint from the Gateway. The configuration >>>>>>>>>>>>>>> relevant to this is >>>>>>>>>>>>>>> in the "api-manager.xml" and it is as follows; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> <RemoveOAuthHeadersFromOutMessage>true</RemoveOAuthHeadersFromOutMessage>* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the value is set to *true *then the Gateway will not >>>>>>>>>>>>>>> pass the access token to the back end and if it's *false*, >>>>>>>>>>>>>>> then it will. Since this configuration resides in the >>>>>>>>>>>>>>> *"api-manager.xml"*, it applies in a "per server" basis. >>>>>>>>>>>>>>> The proposal is to migrate it to the *"tenant-conf.json" >>>>>>>>>>>>>>> *so that this configuration can be applied in a "per >>>>>>>>>>>>>>> tenant" basis. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Solutions:* >>>>>>>>>>>>>>> The design of the proposed solutions for the two problems >>>>>>>>>>>>>>> are as follows: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> i) Proposed workflow for custom header field: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a) Read a configuration from the "tenant-conf.json" for a >>>>>>>>>>>>>>> customized OAuth2 header field. >>>>>>>>>>>>>>> b) Insert the config into the synapse config file that is >>>>>>>>>>>>>>> generated once an API is published, so that it gets deployed in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> Gateway. >>>>>>>>>>>>>>> c) Use the custom header when checking the access token from >>>>>>>>>>>>>>> "APIAuthenticationHandler" for authentication. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> d) If no configuration exists in the "tenant-conf.json", >>>>>>>>>>>>>>> then check for a config in "api-manager.xml" and follow step >>>>>>>>>>>>>>> (b) and (c). >>>>>>>>>>>>>>> This config will act as global config for the server. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> e) If no configuraton exists in the api-manager.xml then the >>>>>>>>>>>>>>> existing workflow will execute using the "Authorization" header >>>>>>>>>>>>>>> field. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ii) Proposed workflow for restricting the access token from >>>>>>>>>>>>>>> being passed to the backend. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a) Read the "RemoveOAuthHeadersFromOutMessage" config from >>>>>>>>>>>>>>> the "tenant-conf.json" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> b) If no config exists in tenant-conf.json, then read it >>>>>>>>>>>>>>> from the "api-manager.xml" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any ideas and suggestions are highly appreciated! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Viduranga. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://docs.wso2.com/display/AM210/Working+with+Access+ >>>>>>>>>>>>>>> Tokens >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Software Engineer Intern* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *WSO2* >>>>>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>> >>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>>>>> >>>>>>>>>>>>> *Software Engineer Intern* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *WSO2* >>>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dinusha Dissanayake >>>>>>>>>>>> Software Engineer >>>>>>>>>>>> WSO2 Inc >>>>>>>>>>>> Mobile: +94712939439 <+94%2071%20293%209439> >>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>>> >>>>>>>>>>> *Software Engineer Intern* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *WSO2* >>>>>>>>>>> Email : [email protected] >>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Chamin Dias >>>>>>>>>> Mobile : 0716097455 <071%20609%207455> >>>>>>>>>> Email : [email protected] >>>>>>>>>> LinkedIn : https://www.linkedin.com/in/chamindias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> >>>>>>>> *Chamalee De Silva* >>>>>>>> Software Engineer >>>>>>>> *WS**O2* Inc. :http://wso2.com/ >>>>>>>> >>>>>>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>>>>>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> *Viduranga Gunarathne* >>>>>>> >>>>>>> *Software Engineer Intern* >>>>>>> >>>>>>> >>>>>>> *WSO2* >>>>>>> Email : [email protected] >>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>> Web : http://wso2.com >>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kishanthan Thangarajah* >>>>>> Technical Lead, >>>>>> Platform Technologies Team, >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - +94773426635 <+94%2077%20342%206635> >>>>>> Blog - *http://kishanthan.wordpress.com >>>>>> <http://kishanthan.wordpress.com>* >>>>>> Twitter - *http://twitter.com/kishanthan >>>>>> <http://twitter.com/kishanthan>* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Dulanja Liyanage >>>>> Lead, Platform Security Team >>>>> WSO2 Inc. >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Kishanthan Thangarajah* >>>> Technical Lead, >>>> Platform Technologies Team, >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - +94773426635 <+94%2077%20342%206635> >>>> Blog - *http://kishanthan.wordpress.com >>>> <http://kishanthan.wordpress.com>* >>>> Twitter - *http://twitter.com/kishanthan >>>> <http://twitter.com/kishanthan>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> *Viduranga Gunarathne* >>> >>> *Software Engineer Intern* >>> >>> >>> *WSO2* >>> Email : [email protected] >>> Mobile : +94712437484 <+94%2071%20243%207484> >>> Web : http://wso2.com >>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>> >> >> >> >> -- >> Regards, >> >> *Viduranga Gunarathne* >> >> *Software Engineer Intern* >> >> >> *WSO2* >> Email : [email protected] >> Mobile : +94712437484 <+94%2071%20243%207484> >> Web : http://wso2.com >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, *Viduranga Gunarathne* *Software Engineer Intern* *WSO2* Email : [email protected] Mobile : +94712437484 <+94%2071%20243%207484> Web : http://wso2.com [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
