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. > 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. [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
