On 20 April 2017 at 19:19, Joseph Fonseka <[email protected]> wrote: > > > On Thu, Apr 20, 2017 at 5:17 PM, Lakmali Baminiwatta <[email protected]> > wrote: >> >> >> So here also, the store users are end users of the test application where >> they can invoke any subscribed APIs with a valid token. Given that we will >> set proper throttling limits as well, I think its not a security >> vulnerability. >> > > Hmm I think still there is an issue, If you consider an API which is > designed to work with client credentials grant the authorization to access > the API will be granted when you subscribe to the API. In the above case > you will get access to the API without subscribing to it ( which I think is > a fundamental issue ). >
@Jo Even though the API is designed to work with client credential, it doesn't mean only the subscribed users can invoke it, right? Any user that access the subscribed app will be able to invoke that API. My argument is, the pattern used in test app is possible in any other normal apps as well. I understand that this can be confusing and might be not easy to convince for some users. However, when proceeding with the implementation we found further problems which we couldn't find clean enough solutions. - Getting the admin apps credentials to the front end for swagger can be vulnerable. Even if we go for implicit grant type, we have to figure out how to compose the callback URLs. - We can do per user app creation with automatic on demand subscriptions (may be with an explicit button as Jo mentioned). If so, only thing we achieve here compared to C4 is doing an automatic subscription/token generation for a default app. So for now, we'll be integrating API Console only for editor and Store. Since API doesn't have security applied in Editor mode, we don't have to worry about token generation. For Store, we will keep the same behavior as in C4 for now. Thanks, Lakmali > Regards > Jo > > >> >> Thanks, >> Lakmali >> >> I guess to prevent that you have to use a per user or per API test app. >>> >>> Regards >>> Jo >>> >>> On Thu, Apr 20, 2017 at 10:10 AM, Lakmali Baminiwatta <[email protected]> >>> wrote: >>> >>>> Hi Jo, >>>> >>>> On 20 April 2017 at 09:01, Joseph Fonseka <[email protected]> wrote: >>>> >>>>> Hi Lakmali >>>>> >>>>> Small thing, will the portal app subscription be automatic in the >>>>> store ? if so can we make it explicit with a button on top of the swagger >>>>> console with the title "Try API with swagger console" and bellow that we >>>>> can explain what actually happens. >>>>> >>>> >>>> We are creating an app for the admin user here and therefore the >>>> subscription happens for the admin user. Therefore IMO, that information is >>>> not required for the store user. >>>> >>>>> >>>>> Also how will the test app affects stats ? If we are not planing to >>>>> hide it better to document that behavior. >>>>> >>>> >>>> The admin user will have this test app. I believe its okay for admin to >>>> have this test app shown may be with a special flag. >>>> >>>> In overall, we can explain the underlying process here when we document >>>> the options users will have around this. >>>> >>>> Thanks, >>>> Lakmali >>>> >>>> >>>>> Thanks >>>>> Jo >>>>> >>>>> On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We had a discussion regarding this yesterday and please find the >>>>>> summarized points. >>>>>> >>>>>> >>>>>> - "Testing APIs" is a required feature for Store and Editor >>>>>> portals. Since we are not restricting API designing only to the >>>>>> editor, but >>>>>> allowed in publisher too, it is good to have "Testing APIs" feature in >>>>>> Publisher for a complete story. >>>>>> - For editor, since the API is published to a local GW, it will >>>>>> not have any security and therefore testing API will not require any >>>>>> tokens/subscriptions etc. >>>>>> - When the API is published from Publisher portal to the GW in >>>>>> CREATED state for testing, we have to apply standard >>>>>> security/throttling to >>>>>> avoid security risks. >>>>>> - As discussed in this thread as well, we will be using the OAuth >>>>>> app created for the portals as the test app. However, for supporting >>>>>> prod >>>>>> and sandbox tokens, we have to register 2 apps. >>>>>> - We can create the test apps when doing the DCR call. >>>>>> - When retrieving the swagger definition of the API, we can check >>>>>> the availability of subscriptions against the test apps and add if not >>>>>> available. >>>>>> - Since swagger itself support OAuth, we can rely on it to obtain >>>>>> a token. For that, we need to inject the test app's credentials to >>>>>> swagger >>>>>> UI and KM details needs to be injected to swagger definition. >>>>>> - We can have a special throttling tier for API testing purpose. >>>>>> - As the first step, we can implement this for Store and then >>>>>> decide on adding it to Publisher. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Lakmali >>>>>> >>>>>> On 24 March 2017 at 19:08, Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> Hi Jo, >>>>>>> >>>>>>> The publisher and store are anyway OAuth apps registered in the IDP. >>>>>>> There are registered under the system/admin user. That is done >>>>>>> irrespective >>>>>>> of the testing usecase so that those apps can use the OAuth protected >>>>>>> Rest >>>>>>> APIs. >>>>>>> >>>>>>> Regarding stats, the stats against the API will show that there are >>>>>>> requests being being from the publisher/store webapps. Which is what >>>>>>> happens in reality. The stats against the application will only be >>>>>>> visible >>>>>>> to the system/admin user since the publisher/store webapps belong to >>>>>>> him. >>>>>>> So it doesn't confuse the end user (actual App Developer on the Store) >>>>>>> like >>>>>>> it does today. >>>>>>> >>>>>>> My thinking is that this testing of the API is mainly for the API >>>>>>> Developers (not publishers) to test the API Implementation code >>>>>>> (ballerina >>>>>>> code) they write. Testing OAuth and throttling are just by-products of >>>>>>> the >>>>>>> main usecase. >>>>>>> >>>>>>> Thanks, >>>>>>> NuwanD. >>>>>>> >>>>>>> On Fri, Mar 24, 2017 at 4:40 PM, Joseph Fonseka <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 24, 2017 at 10:20 AM, Nuwan Dias <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> @Jo, what's the downside of using the Publisher/Store webapp that >>>>>>>>> you're trying to get rid of by explicitly creating a test app? What's >>>>>>>>> the >>>>>>>>> difference basically? >>>>>>>>> >>>>>>>> >>>>>>>> The main issue I see is that automatic subscription of store and >>>>>>>> publisher app. Once subscribed it will come up in IdP , Stats ( If we >>>>>>>> capture ) which will confuse the end user. The second issue is that >>>>>>>> majority of APIs will be just proxy-ed though GW and you wont be >>>>>>>> testing >>>>>>>> the BE functionality at this stage so what you would do is more of an >>>>>>>> integration test with OAuth and throttling hence the user should be >>>>>>>> able to >>>>>>>> utilize all grant types and scopes. >>>>>>>> >>>>>>>> Regards >>>>>>>> Jo >>>>>>>> >>>>>>>> >>>>>>>>> I see a few negatives in allowing to create test apps from the >>>>>>>>> Publisher. >>>>>>>>> >>>>>>>>> 1. The UX is definitely not as good since the user now has to go >>>>>>>>> through additional steps just to test his API. >>>>>>>>> 2. There will be lots of test apps created in the system as >>>>>>>>> opposed to the two webapps. >>>>>>>>> 3. If by any chance the same user visits the Store, we have to >>>>>>>>> find mechanisms to differentiate his test Apps from the Standard Apps >>>>>>>>> so >>>>>>>>> that the test Apps don't appear in Store. >>>>>>>>> 4. If we open up an App creation functionality on the Publisher, >>>>>>>>> chances are that users will misuse this for other purposes. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 24, 2017 at 10:06 AM, Lakmali Baminiwatta < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> The objective of providing this feature is making the API >>>>>>>>>> developers/publisher to test and verify before make it available for >>>>>>>>>> the >>>>>>>>>> consumers. So how about we provide the ability to deploy it to the >>>>>>>>>> gateway >>>>>>>>>> without security so that it can be invoked without a token? >>>>>>>>>> Once the test is completed, they can set the security and publish >>>>>>>>>> that to the store/gateway. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lakmali >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 24 March 2017 at 09:34, Nuwan Dias <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias <[email protected] >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I guess there is a possibility of that API developer not >>>>>>>>>>>>>>>> being the one who publish / create the API ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, the API Developer may not be the same one who's >>>>>>>>>>>>>>> publishing the it. But what's wrong with him testing the API >>>>>>>>>>>>>>> under >>>>>>>>>>>>>>> development using a valid token? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> If this is valid argument then person who create APIs can >>>>>>>>>>>>>> consume it. If we consider scenario where we develop API and >>>>>>>>>>>>>> later it >>>>>>>>>>>>>> published and appear in gateways, just because I'm developer >>>>>>>>>>>>>> will i get >>>>>>>>>>>>>> chance to use this API? I don't think we should allow it. Even >>>>>>>>>>>>>> if we say we >>>>>>>>>>>>>> are testing what actually happen is someone invoke API and get >>>>>>>>>>>>>> results. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In API Manager 3.0.0, the API deployment to the Gateway >>>>>>>>>>>>> happens before the Publishing phase actually. It gets deployed on >>>>>>>>>>>>> the >>>>>>>>>>>>> Gateway as soon as its created. >>>>>>>>>>>>> >>>>>>>>>>>> Why do we deploy API to gateway by the time we created it? >>>>>>>>>>>> Ideally it should go to topic and notified only after publishing >>>>>>>>>>>> it. I >>>>>>>>>>>> haven't noticed it any of our previous discussions. >>>>>>>>>>>> Did i missed something here? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The cause is the same as before. We want to enable API testing >>>>>>>>>>> on the publisher itself so that API developers can test their API >>>>>>>>>>> before >>>>>>>>>>> publishing it to the Store. In order to test an API, it should be >>>>>>>>>>> deployed >>>>>>>>>>> on the Gateway. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> sanjeewa. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If the API developer accessing a published API with a valid >>>>>>>>>>>>> token is a concern, we can automatically remove the publisher >>>>>>>>>>>>> webapp's >>>>>>>>>>>>> subscription to the API once the API gets published. This will >>>>>>>>>>>>> prevent the >>>>>>>>>>>>> API developers and publishers from accessing a published API >>>>>>>>>>>>> since they no >>>>>>>>>>>>> longer have a valid subscription. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>>> This can be an edge case, but if you consider an API >>>>>>>>>>>>>> designed to work with client credentials ie. B2B API, >>>>>>>>>>>>>> subscription is the >>>>>>>>>>>>>> authorization point for that API if so you don't want the >>>>>>>>>>>>>> creator or >>>>>>>>>>>>>> publisher on accessing it ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I guess it is fare to ask a user to go though subscription >>>>>>>>>>>>>> process to test the published API without magic. WDYT ? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, the point here is that we're trying to provide the >>>>>>>>>>>>>>> facility for the Developer to test the API he's developing >>>>>>>>>>>>>>> before >>>>>>>>>>>>>>> publishing it. Because that's a very valid use case. Asking the >>>>>>>>>>>>>>> developer >>>>>>>>>>>>>>> to publish the API and subscribe to it in order to be able to >>>>>>>>>>>>>>> safely test >>>>>>>>>>>>>>> it is not right IMO. The sole reason he wants to test the API >>>>>>>>>>>>>>> first is >>>>>>>>>>>>>>> because he's not ready to publish it yet. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks & Regards >>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 2:32 PM, Nuwan Dias < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Why is it a concern? Its only the App developers who have >>>>>>>>>>>>>>>>> the subscriber role. Almost all consumers of the API are >>>>>>>>>>>>>>>>> general users and >>>>>>>>>>>>>>>>> hence do not have the subscriber role. So why is it a concern >>>>>>>>>>>>>>>>> to allow the >>>>>>>>>>>>>>>>> person who's developing the API to access it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:59 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 23 March 2017 at 13:46, Joseph Fonseka < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:01 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In publisher shouldn't we invoke the API back-end >>>>>>>>>>>>>>>>>>>>> instead of Gateway ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I guess publisher may need to test the API execution >>>>>>>>>>>>>>>>>>>> flow through gateway. For instance the resource paths, >>>>>>>>>>>>>>>>>>>> mediation logics, >>>>>>>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes that make sense, but if we automatically subscribe >>>>>>>>>>>>>>>>>>> to a published API it will allow a user ( ie user with >>>>>>>>>>>>>>>>>>> creator role in >>>>>>>>>>>>>>>>>>> publisher ) who may not have subscription permission to >>>>>>>>>>>>>>>>>>> invoke an API. That >>>>>>>>>>>>>>>>>>> might be a security concern based on a company policy. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, this can be a valid concern. In that case we can >>>>>>>>>>>>>>>>>> allow this only for users with publish permissions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Or are we only allowing the test feature in publisher for >>>>>>>>>>>>>>>>>>> specific roles. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> IMO it would be difficult to explain the mention >>>>>>>>>>>>>>>>>>>>> approach to a user than what we have. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks & Regards >>>>>>>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The proposed solution is to generate an access token >>>>>>>>>>>>>>>>>>>>>> with the UUF app's credentials + special scope. The >>>>>>>>>>>>>>>>>>>>>> subscription validation >>>>>>>>>>>>>>>>>>>>>> will be skipped for the tokens in this special scope. >>>>>>>>>>>>>>>>>>>>>> For implementing the >>>>>>>>>>>>>>>>>>>>>> solution, we have to consider below points. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Grant Type - If the client_credentials grant >>>>>>>>>>>>>>>>>>>>>> type is used, all the concurrent users accessing the >>>>>>>>>>>>>>>>>>>>>> UI app will get the >>>>>>>>>>>>>>>>>>>>>> same token. In order to do any user level >>>>>>>>>>>>>>>>>>>>>> restrictions for this token in >>>>>>>>>>>>>>>>>>>>>> the gateway level, we have to use password grant >>>>>>>>>>>>>>>>>>>>>> type. One case is >>>>>>>>>>>>>>>>>>>>>> visibility restricted API invocations. Also I guess >>>>>>>>>>>>>>>>>>>>>> we shouldn't allow to >>>>>>>>>>>>>>>>>>>>>> invoke API resources protected with scopes if the >>>>>>>>>>>>>>>>>>>>>> logged in user is not >>>>>>>>>>>>>>>>>>>>>> allowed for that. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Scope white listing - This scope has to be >>>>>>>>>>>>>>>>>>>>>> white listed, since the API resource is not actually >>>>>>>>>>>>>>>>>>>>>> protected with it. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Throttling - Since there is no API >>>>>>>>>>>>>>>>>>>>>> subscription, special throttle limit has to be >>>>>>>>>>>>>>>>>>>>>> applied with some minimum >>>>>>>>>>>>>>>>>>>>>> quota. One option is to apply the unauthenticated >>>>>>>>>>>>>>>>>>>>>> tier limits which does a >>>>>>>>>>>>>>>>>>>>>> throttling based on the client IP. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Token validity and refresh token - If the >>>>>>>>>>>>>>>>>>>>>> client_credential grant type is used, we can't >>>>>>>>>>>>>>>>>>>>>> invalidate this test token >>>>>>>>>>>>>>>>>>>>>> when a user is logged out since other users might be >>>>>>>>>>>>>>>>>>>>>> using it already. >>>>>>>>>>>>>>>>>>>>>> Therefore IMO, we can use password grant type and use >>>>>>>>>>>>>>>>>>>>>> the similar token >>>>>>>>>>>>>>>>>>>>>> refreshing mechanism done for UUF app authentication. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Obtaining the access token - In order to get an >>>>>>>>>>>>>>>>>>>>>> access token, we need the consumer key and secret of >>>>>>>>>>>>>>>>>>>>>> the UUF app. Currently >>>>>>>>>>>>>>>>>>>>>> we do a UUF backend app call only when the user is >>>>>>>>>>>>>>>>>>>>>> authenticating or when >>>>>>>>>>>>>>>>>>>>>> refreshing the token. So here also, I think we can >>>>>>>>>>>>>>>>>>>>>> generate the test token >>>>>>>>>>>>>>>>>>>>>> when the user is authenticated(log in to the UUF app) >>>>>>>>>>>>>>>>>>>>>> and store it in the >>>>>>>>>>>>>>>>>>>>>> local storage. I believe its okay to display this >>>>>>>>>>>>>>>>>>>>>> access token for the >>>>>>>>>>>>>>>>>>>>>> user. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>> >>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>> >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Nuwan Dias >>>>>>>>>>> >>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>> email : [email protected] >>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>> Associate Technical Lead >>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>> blog : lakmali.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : [email protected] >>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> -- >>>>>>>> *Joseph Fonseka* >>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> mobile: +94 772 512 430 >>>>>>>> skype: jpfonseka >>>>>>>> >>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lakmali Baminiwatta >>>>>> Associate Technical Lead >>>>>> WSO2, Inc.: http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> mobile: +94 71 2335936 >>>>>> blog : lakmali.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> -- >>>>> *Joseph Fonseka* >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: +94 772 512 430 >>>>> skype: jpfonseka >>>>> >>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Lakmali Baminiwatta >>>> Associate Technical Lead >>>> WSO2, Inc.: http://wso2.com >>>> lean.enterprise.middleware >>>> mobile: +94 71 2335936 >>>> blog : lakmali.com >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> -- >>> *Joseph Fonseka* >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 772 512 430 >>> skype: jpfonseka >>> >>> * <http://lk.linkedin.com/in/rumeshbandara>* >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Lakmali Baminiwatta >> Associate Technical Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Lakmali Baminiwatta Associate Technical Lead WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 blog : lakmali.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
