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. 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
