On Tue, Aug 20, 2019 at 4:27 PM Harsha Kumara <[email protected]> wrote:
> > > On Tue, Aug 20, 2019 at 3:35 PM Bhathiya Jayasekara <[email protected]> > wrote: > >> >> >> On Tue, Aug 20, 2019 at 3:27 PM Malintha Amarasinghe <[email protected]> >> wrote: >> >>> >>> >>> On Mon, 19 Aug 2019, 20:01 Vithursa Mahendrarajah, <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> I have started the implementation. When giving roles with userstore >>>> domain name separated with "/", *HTTP/1.1 400 Bad Request* error >>>> response is returned, as encoded slashes is not allowed by default in >>>> tomcat. As suggested in [1], when adding the system property >>>> *org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true*, this >>>> issue is sorted. >>>> >>>> After this changes, the request to validate roles in secondary >>>> user-store fails with the error response - *HTTP/1.1 401 Unauthorized*. >>>> It is due to failed scope validation in [2]. This behavior is observed >>>> because the path parameter is decoded during authentication phase. After >>>> analysis found that, currently we are using >>>> *org.apache.cxf.message.Message.PATH_INFO* parameter ([3]) from >>>> request which has the decoded value. In order to resolve this issue, we can >>>> use *org.apache.cxf.request.uri* parameter in message which is encoded. >>>> >>>> For instance, for the request URL - >>>> https://localhost:9443/api/am/publisher/v1.0/roles/*Internal%2Fcreator*, >>>> >>>> org.apache.cxf.message.Message.PATH_INFO: >>>> "/api/am/publisher/v1.0/roles/Internal/creator" >>>> org.apache.cxf.request.uri: >>>> "/api/am/publisher/v1.0/roles/Internal%2Fcreator" >>>> >>>> If we are proceeding with the following format of request, we need to >>>> add the system property and make relevant changes in scope validation logic >>>> (WebAppAuthenticatorImpl.java): >>>> https://localhost:9443/api/am/publisher/v1.0/roles/ >>>> *{user-store-name}/{role-name}* >>>> >>>> However, found [5], [6] related to the security concerns in setting >>>> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH as true by default. >>>> >>>> The * org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH* and >>>>> *org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH* system >>>>> properties allow non-standard parsing of the request URI. Using these >>>>> options when behind a reverse proxy may enable an attacker to bypass any >>>>> security constraints enforced by the proxy. >>>>> >>>> >>> This is a good finding. Given this issue, I don't think it is a good >>> idea to proceed with the encoded slash in the path. >>> >>>> >>>> Alternatively, we can pass user-store in following ways: >>>> >>>> 1. /roles/{rolename}?userstore={userstore} >>>> 2. /userstore/{userstore}/roles/{roleName} >>>> 3. /roles/{rolename}/userstore/{userstore} >>>> 4. Or, need to have a configurable character to differentiate >>>> user-store and role name. For instance, roles/{userstore}*-* >>>> {roleName} >>>> >>>> Which way we can implement? Appreciate your suggestions regarding this. >>>> >>> >>> How do we treat Internal roles? Can we treat "Internal" as a user store? >>> >>> Eg: check if "Internal/subscriber" is available: >>> >>> HEAD /roles/subscriber?userStore=Internal >>> >>> Is this a valid way of representing it? >>> >> >> If we're not allowed to create secondary userstores with the name >> "Internal", this should be ok. >> > For internal roles should be pass this at all? > That should be the behavior for the users in the primary user store right? Thanks, Bhathiya > >> Thanks, >> Bhathiya >> >> >>> >>> >>>> >>>> [1] https://issues.apache.org/jira/browse/CXF-4207 >>>> [2] >>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java#L138 >>>> [3] >>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/impl/WebAppAuthenticatorImpl.java#L113 >>>> [4] >>>> https://serverfault.com/questions/914847/stop-apache-from-decoding-characters-from-uri-for-path-info >>>> [5] https://backstage.forgerock.com/knowledge/kb/article/a59558448 >>>> [6] >>>> http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Properties >>>> <http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html> >>>> >>>> <http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html> >>>> Thanks, >>>> Vithursa >>>> >>>> On Fri, Aug 16, 2019 at 11:07 AM Vithursa Mahendrarajah < >>>> [email protected]> wrote: >>>> >>>>> Ack, will do that. >>>>> >>>>> On Fri, Aug 16, 2019 at 12:16 AM Harsha Kumara <[email protected]> >>>>> wrote: >>>>> >>>>>> @Vithursa Mahendrarajah <[email protected]> Once you implement, >>>>>> let's add several test cases with special characters, secondary user >>>>>> store >>>>>> roles and etc. >>>>>> >>>>>> On Thu, Aug 15, 2019 at 4:16 PM Vithursa Mahendrarajah < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Thanks for the suggestions. As per the suggestions, we have decided >>>>>>> to go with HEAD request option. As mentioned earlier in this thread, >>>>>>> following are the scenarios where role validation is required: >>>>>>> >>>>>>> 1. API Design phase - >>>>>>> - Publisher access control - check whether the role exists and >>>>>>> the logged-in user has the role >>>>>>> - Store visibility - check whether the role exists or not >>>>>>> 2. API Manage phase - when adding new scope - check whether the >>>>>>> role exists or not >>>>>>> >>>>>>> We have decided to add the OAuth2 scope as apim:api_create as these >>>>>>> functionalities are used by API creator. >>>>>>> >>>>>>> As per the offline discussion had with @Malintha Amarasinghe >>>>>>> <[email protected]> and @Kasun Thennakoon <[email protected]>, >>>>>>> when checking whether the logged-in user has particular role, claims in >>>>>>> ID >>>>>>> token stored in browser local storage could be used. By considering the >>>>>>> possibility of manipulating the ID token in local storage, complexity in >>>>>>> handling when using secondary userstore and the security concerns in >>>>>>> exposing roles assigned to particular user, we have decided to >>>>>>> introduce another REST API to check whether the logged-in user has the >>>>>>> given role as this would be more cleaner. >>>>>>> >>>>>>> Please find the REST API definition as follows: >>>>>>> >>>>>>> ###################################################### >>>>>>> # The Role Name Existence >>>>>>> ###################################################### >>>>>>> /roles/{roleName}: >>>>>>> #----------------------------------------------------- >>>>>>> # The role name existence check resource >>>>>>> #----------------------------------------------------- >>>>>>> head: >>>>>>> security: >>>>>>> - OAuth2Security: >>>>>>> - apim:api_create >>>>>>> summary: >>>>>>> Check given role name already exists >>>>>>> description: >>>>>>> Using this operation, to check whether given role already exists >>>>>>> parameters: >>>>>>> - $ref : '#/parameters/roleName' >>>>>>> responses: >>>>>>> 200: >>>>>>> description: >>>>>>> OK. >>>>>>> Requested role name is returned. >>>>>>> 404: >>>>>>> description: >>>>>>> Not Found. >>>>>>> Requested role name does not exist. >>>>>>> >>>>>>> ###################################################### >>>>>>> # The Role Name Existence for the logged-in user >>>>>>> ###################################################### >>>>>>> /me/roles/{roleName}: >>>>>>> #----------------------------------------------------- >>>>>>> # Validate role against a user >>>>>>> #----------------------------------------------------- >>>>>>> head: >>>>>>> security: >>>>>>> - OAuth2Security: >>>>>>> - apim:api_create >>>>>>> summary: >>>>>>> Validate whether the logged-in user has the given role >>>>>>> description: >>>>>>> Using this operation, logged-in user can check whether he has >>>>>>> given role. >>>>>>> parameters: >>>>>>> - $ref : '#/parameters/roleName' >>>>>>> responses: >>>>>>> 200: >>>>>>> description: >>>>>>> OK. >>>>>>> Logged-in user has the role. >>>>>>> 404: >>>>>>> description: >>>>>>> Not Found. >>>>>>> Logged-in user does not have the role. >>>>>>> >>>>>>> Appreciate any feedback on this. >>>>>>> >>>>>>> Thanks, >>>>>>> Vithursa >>>>>>> >>>>>>> On Thu, Aug 15, 2019 at 11:35 AM Naduni Pamudika <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> +Vithursa Mahendrarajah <[email protected]> >>>>>>>> >>>>>>>> On Mon, Aug 12, 2019 at 5:26 PM Sanjeewa Malalgoda < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Aug 8, 2019 at 9:08 PM Malintha Amarasinghe < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> When we return a 404, it implies that the URL (or the resource) >>>>>>>>>> does not exist. Here the URL/resource is */validate-role *(a >>>>>>>>>> controller resource) which always exists so it is wrong to return a >>>>>>>>>> 404 at >>>>>>>>>> any case. >>>>>>>>>> >>>>>>>>> Yes agree with this and controller resource(as query params >>>>>>>>> optional controller resource will be resource) is not ideal for this. >>>>>>>>> Using head would be good option. Like nirmal mentioned any >>>>>>>>> additional parameters related to filter criteria can be passed as >>>>>>>>> query >>>>>>>>> parameters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> sanjeewa/ >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> On Thu, Aug 8, 2019 at 7:12 PM Menaka Jayawardena < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Naduni, >>>>>>>>>>> >>>>>>>>>>> Wh the GET request always returns 200? >>>>>>>>>>> Can't we set the status code 404 if the role is not found? So we >>>>>>>>>>> can check the response status from the UI. We do not want to read >>>>>>>>>>> the body >>>>>>>>>>> then. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 8, 2019 at 6:05 PM Naduni Pamudika <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Thanks all for the suggestions. With the GET method @Bhathiya >>>>>>>>>>>> Jayasekara <[email protected]> suggested, we have the >>>>>>>>>>>> following 2 options now. >>>>>>>>>>>> >>>>>>>>>>>> 1. *HEAD /roles/{roleName}* >>>>>>>>>>>> 2. *GET /validate-role?role=rolename* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If we go with the option 1, it will simplify the work in the UI >>>>>>>>>>>> side while doing the role validations by using the Rest API since >>>>>>>>>>>> we can do >>>>>>>>>>>> the validation by looking at the status code (If the role exists >>>>>>>>>>>> it is a >>>>>>>>>>>> 200 and if not it is a 404). If we go with the option 2, it will >>>>>>>>>>>> always >>>>>>>>>>>> return a 200 status code and we need to check the response body to >>>>>>>>>>>> validate >>>>>>>>>>>> a particular role name (We can send *isRoleExist=true* and >>>>>>>>>>>> *isRoleExist=false* in the response body depending on the >>>>>>>>>>>> existence of a role name). >>>>>>>>>>>> >>>>>>>>>>>> Since most of us are +1 with the option 2, shall we move >>>>>>>>>>>> forward with the GET method? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Naduni >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 7, 2019 at 7:27 PM Bhathiya Jayasekara < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 7, 2019 at 6:24 PM Malintha Amarasinghe < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:39 PM Harsha Kumara < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:37 PM Malintha Amarasinghe < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:35 PM Harsha Kumara < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Let's say if someone wants to check existence of role foo >>>>>>>>>>>>>>>>> in user store TEST. He will do a call /roke/TEST/foo which >>>>>>>>>>>>>>>>> isn't valid >>>>>>>>>>>>>>>>> request right? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Harsha Kumara <[email protected]> we need to URL encode >>>>>>>>>>>>>>>> the role name. The request will become /roles/TEST%2Ffoo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes that's true. Again some customers might have different >>>>>>>>>>>>>>> letters in their role names. Might note be a good idea to >>>>>>>>>>>>>>> include as a path >>>>>>>>>>>>>>> parameter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Even if we add as a query param, that will go as part of the >>>>>>>>>>>>>> URL which might lead to similar issues? We may need to test this >>>>>>>>>>>>>> for query >>>>>>>>>>>>>> parameters as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preferred the HEAD method due to the simpleness ( only need >>>>>>>>>>>>>> to respond with 204 or 404 without any payload based on the >>>>>>>>>>>>>> availability of >>>>>>>>>>>>>> the role) and RESTfulness (consider a role as a resource and do >>>>>>>>>>>>>> a fetch on >>>>>>>>>>>>>> it in the usual way). HEAD is the usual way for checking the >>>>>>>>>>>>>> existence of a >>>>>>>>>>>>>> resource. However, we do not have the need for implementing a >>>>>>>>>>>>>> GET here for >>>>>>>>>>>>>> now. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is actually my worry is. I don't think we'll ever have to >>>>>>>>>>>>> give a /roles/{role} in the publisher APIs. So having a HEAD >>>>>>>>>>>>> without a GET >>>>>>>>>>>>> feels strange to me. Maybe it's just me. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bhathiya >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:33 PM Mushthaq Rumy < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adding [Architecture] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:30 PM Mushthaq Rumy < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Since we will be UserStoreManager, this should cover the >>>>>>>>>>>>>>>>>>> secondary user stores as well. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>>>>>> Mushthaq >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:28 PM Harsha Kumara < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What happen if the role is from secondary user store? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:24 PM Naduni Pamudika < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We are planning to add a REST API endpoint to APIM 3.0 >>>>>>>>>>>>>>>>>>>>> Publisher Rest APIs and the intention is to check the >>>>>>>>>>>>>>>>>>>>> existence of a >>>>>>>>>>>>>>>>>>>>> particular role name. This will be used in order to >>>>>>>>>>>>>>>>>>>>> manage roles when >>>>>>>>>>>>>>>>>>>>> enabling Publisher Access Control and Store Visibility >>>>>>>>>>>>>>>>>>>>> and when adding >>>>>>>>>>>>>>>>>>>>> Scopes. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The swagger definition for the new endpoint would be >>>>>>>>>>>>>>>>>>>>> as follows. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ###################################################### >>>>>>>>>>>>>>>>>>>>> # The Role Name Existence >>>>>>>>>>>>>>>>>>>>> ###################################################### >>>>>>>>>>>>>>>>>>>>> /roles/{roleName}: >>>>>>>>>>>>>>>>>>>>> #----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>> # The role name existence check resource >>>>>>>>>>>>>>>>>>>>> #----------------------------------------------------- >>>>>>>>>>>>>>>>>>>>> head: >>>>>>>>>>>>>>>>>>>>> security: >>>>>>>>>>>>>>>>>>>>> - OAuth2Security: >>>>>>>>>>>>>>>>>>>>> - apim:api_view >>>>>>>>>>>>>>>>>>>>> summary: | >>>>>>>>>>>>>>>>>>>>> Check given role name is already exist >>>>>>>>>>>>>>>>>>>>> description: | >>>>>>>>>>>>>>>>>>>>> Using this operation, you can check a >>>>>>>>>>>>>>>>>>>>> given role name is already used. You need to provide the >>>>>>>>>>>>>>>>>>>>> role name you want >>>>>>>>>>>>>>>>>>>>> to check. >>>>>>>>>>>>>>>>>>>>> parameters: >>>>>>>>>>>>>>>>>>>>> - $ref : '#/parameters/roleName' >>>>>>>>>>>>>>>>>>>>> responses: >>>>>>>>>>>>>>>>>>>>> 200: >>>>>>>>>>>>>>>>>>>>> description: | >>>>>>>>>>>>>>>>>>>>> OK. >>>>>>>>>>>>>>>>>>>>> Requested role name is returned. >>>>>>>>>>>>>>>>>>>>> 404: >>>>>>>>>>>>>>>>>>>>> description: | >>>>>>>>>>>>>>>>>>>>> Not Found. >>>>>>>>>>>>>>>>>>>>> Requested role name does not exist. >>>>>>>>>>>>>>>>>>>>> ###################################################### >>>>>>>>>>>>>>>>>>>>> # Role Name >>>>>>>>>>>>>>>>>>>>> roleName: >>>>>>>>>>>>>>>>>>>>> name: roleName >>>>>>>>>>>>>>>>>>>>> in: path >>>>>>>>>>>>>>>>>>>>> description: | >>>>>>>>>>>>>>>>>>>>> The role name >>>>>>>>>>>>>>>>>>>>> required: true >>>>>>>>>>>>>>>>>>>>> type: string >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It is a HEAD method (*/roles/{roleName}*) which will >>>>>>>>>>>>>>>>>>>>> return a 200 status code if the given role name exists >>>>>>>>>>>>>>>>>>>>> and a 404 status >>>>>>>>>>>>>>>>>>>>> code if the give role name is not found. Sample requests >>>>>>>>>>>>>>>>>>>>> and responses are >>>>>>>>>>>>>>>>>>>>> given below. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Request: >>>>>>>>>>>>>>>>>>>>> HEAD >>>>>>>>>>>>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/valid-role >>>>>>>>>>>>>>>>>>>>> HTTP/1.1 >>>>>>>>>>>>>>>>>>>>> Authorization: Bearer >>>>>>>>>>>>>>>>>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Response: >>>>>>>>>>>>>>>>>>>>> HTTP/1.1 200 OK >>>>>>>>>>>>>>>>>>>>> Connection: keep-alive >>>>>>>>>>>>>>>>>>>>> Content-Length: 0 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Request: >>>>>>>>>>>>>>>>>>>>> HEAD >>>>>>>>>>>>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/invalid-role >>>>>>>>>>>>>>>>>>>>> HTTP/1.1 >>>>>>>>>>>>>>>>>>>>> Authorization: Bearer >>>>>>>>>>>>>>>>>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Response: >>>>>>>>>>>>>>>>>>>>> HTTP/1.1 404 Not Found >>>>>>>>>>>>>>>>>>>>> Connection: keep-alive >>>>>>>>>>>>>>>>>>>>> Content-Length: 0 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Are we good to have the endpoint definition as this? >>>>>>>>>>>>>>>>>>>>> Appreciate your inputs to proceed further. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Naduni >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 >>>>>>>>>>>>>>>>>>>>> Inc. >>>>>>>>>>>>>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) >>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>> [image: http://wso2.com/signature] >>>>>>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Mushthaq Rumy >>>>>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140 >>>>>>>>>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Mushthaq Rumy >>>>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140 >>>>>>>>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Malintha Amarasinghe >>>>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>>>>>>>>>> http://wso2.com/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mobile : +94 712383306 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Malintha Amarasinghe >>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>>>>>>>> http://wso2.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mobile : +94 712383306 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. >>>>>>>>>>>>> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc. >>>>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) >>>>>>>>>>>> [email protected] >>>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> *Menaka Jayawardena* >>>>>>>>>>> Senior Software Engineer | WSO2 Inc. >>>>>>>>>>> +94 71 350 5470 | +94 76 717 2511 | [email protected] >>>>>>>>>>> >>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Malintha Amarasinghe >>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>>>> http://wso2.com/ >>>>>>>>>> >>>>>>>>>> Mobile : +94 712383306 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc. >>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) [email protected] >>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vithursa Mahendrarajah >>>>>>> Software Engineer >>>>>>> WSO2 Inc. - http ://wso2.com >>>>>>> Mobile : +947*66695643* <+94%2077%20819%201300> >>>>>>> >>>>>>> >>>>>>> * <http://wso2.com/signature> <http://wso2.com/signature> >>>>>>> <http://wso2.com/signature>* >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Harsha Kumara* >>>>>> >>>>>> Technical Lead, WSO2 Inc. >>>>>> Mobile: +94775505618 >>>>>> Email: [email protected] >>>>>> Blog: harshcreationz.blogspot.com >>>>>> >>>>>> GET INTEGRATION AGILE >>>>>> Integration Agility for Digitally Driven Business >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vithursa Mahendrarajah >>>>> Software Engineer >>>>> WSO2 Inc. - http ://wso2.com >>>>> Mobile : +947*66695643* <+94%2077%20819%201300> >>>>> >>>>> >>>>> * <http://wso2.com/signature> <http://wso2.com/signature> >>>>> <http://wso2.com/signature>* >>>>> >>>> >>>> >>>> -- >>>> Vithursa Mahendrarajah >>>> Software Engineer >>>> WSO2 Inc. - http ://wso2.com >>>> Mobile : +947*66695643* <+94%2077%20819%201300> >>>> >>>> >>>> * <http://wso2.com/signature> <http://wso2.com/signature> >>>> <http://wso2.com/signature>* >>>> >>> >> >> -- >> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. >> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com >> >> >> > > -- > > *Harsha Kumara* > > Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: [email protected] > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
