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