On Tue, Aug 20, 2019 at 3:35 PM Bhathiya Jayasekara <bhath...@wso2.com> wrote:
> > > On Tue, Aug 20, 2019 at 3:27 PM Malintha Amarasinghe <malint...@wso2.com> > wrote: > >> >> >> On Mon, 19 Aug 2019, 20:01 Vithursa Mahendrarajah, <vithu...@wso2.com> >> 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? > > 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 < >>> vithu...@wso2.com> wrote: >>> >>>> Ack, will do that. >>>> >>>> On Fri, Aug 16, 2019 at 12:16 AM Harsha Kumara <hars...@wso2.com> >>>> wrote: >>>> >>>>> @Vithursa Mahendrarajah <vithu...@wso2.com> 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 < >>>>> vithu...@wso2.com> 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 >>>>>> <malint...@wso2.com> and @Kasun Thennakoon <kasu...@wso2.com>, 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 <nad...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> +Vithursa Mahendrarajah <vithu...@wso2.com> >>>>>>> >>>>>>> On Mon, Aug 12, 2019 at 5:26 PM Sanjeewa Malalgoda < >>>>>>> sanje...@wso2.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 8, 2019 at 9:08 PM Malintha Amarasinghe < >>>>>>>> malint...@wso2.com> 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 <men...@wso2.com> >>>>>>>>> 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 <nad...@wso2.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Thanks all for the suggestions. With the GET method @Bhathiya >>>>>>>>>>> Jayasekara <bhath...@wso2.com> 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 < >>>>>>>>>>> bhath...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 7, 2019 at 6:24 PM Malintha Amarasinghe < >>>>>>>>>>>> malint...@wso2.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:39 PM Harsha Kumara <hars...@wso2.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:37 PM Malintha Amarasinghe < >>>>>>>>>>>>>> malint...@wso2.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:35 PM Harsha Kumara < >>>>>>>>>>>>>>> hars...@wso2.com> 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 <hars...@wso2.com> 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 < >>>>>>>>>>>>>>>> musht...@wso2.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adding [Architecture] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:30 PM Mushthaq Rumy < >>>>>>>>>>>>>>>>> musht...@wso2.com> 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 < >>>>>>>>>>>>>>>>>> hars...@wso2.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What happen if the role is from secondary user store? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Aug 7, 2019 at 3:24 PM Naduni Pamudika < >>>>>>>>>>>>>>>>>>> nad...@wso2.com> 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) >>>>>>>>>>>>>>>>>>>> nad...@wso2.com >>>>>>>>>>>>>>>>>>>> [image: http://wso2.com/signature] >>>>>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>>>>>> Email: hars...@wso2.coim >>>>>>>>>>>>>>>>>>> Blog: harshcreationz.blogspot.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> GET INTEGRATION AGILE >>>>>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Mushthaq Rumy >>>>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140 >>>>>>>>>>>>>>>>>> Email : musht...@wso2.com >>>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Mushthaq Rumy >>>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>>> Mobile : +94 (0) 779 492140 >>>>>>>>>>>>>>>>> Email : musht...@wso2.com >>>>>>>>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Harsha Kumara* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Technical Lead, WSO2 Inc. >>>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>>> Email: hars...@wso2.coim >>>>>>>>>>>>>>>> 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: hars...@wso2.coim >>>>>>>>>>>>>> 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) >>>>>>>>>>> nad...@wso2.com >>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Menaka Jayawardena* >>>>>>>>>> Senior Software Engineer | WSO2 Inc. >>>>>>>>>> +94 71 350 5470 | +94 76 717 2511 | men...@wso2.com >>>>>>>>>> >>>>>>>>>> <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) sanje...@wso2.com | (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) nad...@wso2.com >>>>>>> [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: hars...@wso2.coim >>>>> 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: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
