+1 on this discussion Given the risks, I propose we deprecate the self-service API on fineract1.x., or note that it should only be used for demo or prototype purposes. (while functionally powerful and useful for demos, it potentially introduces too many issues into a production environment)
In recent work on mojaloop integration with fineract1.x, the gap of well designed "channels" architecture i.e. web channel vs mobile channel, was made clear. The requirement is for secure front ends that evolve separately - As noted by @Vishwas Babu <[email protected]> "Back-office CBS and customer-self service has clearly demarcated boundaries" @davidyaha Thank you. Since we are on the topic of security, I would recommend we look at the OWASP project approach and its top 10 threats to web apps. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project e.g. A1-Injection, A2-Broken Authentication,.... A5-Broken Access Control, A6-Security Misconfiguration, and so on... We could also look at other relevant security frameworks. e.g. PCI-DSS or ISO/IEC 27001 but I think a focus on the OWASP top ten would be a better place to start. James Dailey skype: jdailey On Tue, Feb 12, 2019 at 10:51 AM Markus Geiss <[email protected]> wrote: > I'm not sure if offline first would higher complexity. > > It will have a few benefits, e.g. the used data model on the client can't > be based on the wanted view model, the application will always be available > to the end user, an app developer can focus on the UI/UX, and a backend > developer can make the magic happen on the service side. > > I do believe that trying to model an online app calling any type of backend > service directly is way more complex, you need to care about all the > special cases where connectivity is not given, either when starting the > app, or in between while you are working. > > The nice things about PouchDB/CouchDB and the Sync gateway is, that this is > handled by those tools. > > Just my two cents, if I need to create any type of mobile application I > would always design it to be offline first. > > Cheers > > Markus > > > > On Tue, Feb 12, 2019 at 6:39 PM Vishwas Babu < > [email protected]> wrote: > > > As Self service functionality for an organization serving SME’s is quite > > different from those providing digital wallets or serving Agent > networks, > > the bigger question here would be , What is the scope of the customer > > facing functionality and if offline first functionality makes sense for > the > > same ? > > > > On a sidebar, It would help to keep this scope minimal and ideally linked > > to a customer looking to take it to production and focus any additional > dev > > cycles organizations like the Mifos Initiative can spare on deepening the > > portfolio / deposits and accounting modules which would have a > > significantly larger audience. > > > > Regards, > > Vishwas > > > > > > > > On Tuesday, February 12, 2019, Myrle Krantz <[email protected]> wrote: > > > > > My current thinking on customer facing functionality is that, for an > > > offline-first strategy, we should place a PouchDB/CouchDB > database/cache > > > between the customer app and any APIs. Domain-driven design does not > > > (necessarily) mean that all self-service functionality must land in one > > > microservice. For example, customer authentication should probably be > > > handled in a service separately from retrieving account information > (and > > > separately from back-office employee authentication). > > > > > > Best Regards, > > > Myrle > > > > > > On Tue, Feb 12, 2019 at 1:28 PM Vishwas Babu < > > > [email protected]> wrote: > > > > > > > Hi All, > > > > > > > > Adding some context based on our (Conflux Technologies) experiences > > with > > > > MifosX / Fineract 1.x and summarizing a recent discussion I had with > a > > > > community member. > > > > > > > > When it comes to customer self-service, the kind of institutions that > > we > > > > have come across can be broadly divided into three categories > > > > > > > > Bucket 1: > > > > Traditional MFI's and Fintech lenders providing customers views of > > their > > > > accounts through online, USSD and IVR channels. These organizations > > also > > > > offer customers the ability to originate new accounts online. > > > > A majority of the current Fineract1.x users would fall into this > bucket > > > > > > > > Bucket 2: > > > > Digital banks and Fintech companies which provide additional > > self-service > > > > capabilities including digital wallets, bill payments, money > transfers > > > and > > > > remittances. Interesting needs in this sector include features like > > money > > > > transfers without an active internet connection through channels like > > > call > > > > back IVR. > > > > > > > > Bucket 3: > > > > Financial Institutions with agents and business correspondents who > > > > sometimes model their agents as customers with additional privileges > > and > > > > serve them through enhanced customer self-service apps. > > > > This sector occasionally has the need for offline functionality ( > which > > > is > > > > robust only when combined with organization enforced business rules ) > > > > > > > > These applications themselves are built out independently and > interface > > > > with Fineract 1.x through the available back-office API's (NOT the > > > > self-service API's which provide each customer a separate login) and > > > > webhook callbacks. Some of the reasoning behind this approach as > > against > > > > thin UI's talking directly to Fineract 1.x are listed below. With the > > > > architecture followed in Fineract-CN, when customer self-service > API's > > > are > > > > exposed through a new microservice, a majority of these items would > be > > > > automatically taken care of and we would then only have to contend > with > > > the > > > > threat list that David alludes to. > > > > > > > > -> Back-office CBS and customer-self service has clearly demarcated > > > > boundaries > > > > Tying them up in a single deployable unit would hinder their ability > to > > > > evolve independently. Organizations tend to be very opinionated about > > > > self-service channels and these apps follow short release cycles with > > > some > > > > amount of customization going into each new implementation. > > > > - A customer on the self-service app needn't necessarily be present > on > > > the > > > > CBS. > > > > Ex: Self-service apps for organizations like Fintech lenders > typically > > > > allow users to sign up, create a profile and apply for a loan. > > > > - Customer/loans/savings statuses and lifecycle on the self-service > app > > > do > > > > not map directly with those on the CBS. > > > > For example, an application initiated by a customer goes through a > > > process > > > > of automated and manual sanity checks on the self-service apps, after > > > which > > > > they are moved to the CBS with a predefined state to join the regular > > > > workflow (de-duplication, eligibility and credit checks etc). This is > > > > typically different from the lifecycle of an application originated > by > > a > > > > teller. > > > > - Fine-grained control is required on the granularity of information > > > > presented on the self-service apps, which is different from that > > > presented > > > > to the back office. Ex: All products in the CBS are not shown as > > options > > > in > > > > the self-service portal. Similarly, for the products that are shown, > > the > > > > granularity of information in the terms is a greatly reduced subset > of > > > that > > > > available in the product definition at the CBS. > > > > > > > > -> Deployment and scalability scenarios > > > > While these issues can be easily addressed through a combination of > > code > > > > modifications on the self-service API's of Fineract 1.x and > deployment > > > > configurations, they have been listed here for completeness. > > > > - Client facing apps need to be scaled independently of back-office > > > facing > > > > CBS and also need to have different configurations for rate limiting > > etc. > > > > - The client-facing apps should cache all lookup data fetched from > the > > > CBS, > > > > route read traffic to a cluster of Fineract1.x servers talking to > > > > replicated databases etc to ensure that the traffic to the cluster > > > serving > > > > the back-office is kept to a minimum and remains largely unaffected > by > > > > spikes in customer traffic. > > > > - Easy to turn off, monitor and audit client-self service happening > > > through > > > > a single login at Fineract 1.x > > > > > > > > -> Security implications > > > > While these issues can be easily addressed through a combination of > > code > > > > modifications on the self-service API's of Fineract 1.x and > deployment > > > > configurations, they have been listed here for completeness. > > > > - Organizations might not want to expose their CBS outside of their > VPN > > > > - The security needs of client facing apps are radically different > from > > > > those of a back-office CBS and vary from organization to > organization. > > > Ex: > > > > Organizations serving SME's need separate makers and approvers for > each > > > > transaction, organizations need logged in users to enter separate > > > > transaction passwords + OTP's for authorizing each transaction etc. > > > > > > > > Regards, > > > > Vishwas > > > > > > > > > > > > > > > > On Mon, Jan 14, 2019 at 10:54 AM Ed Cable <[email protected]> wrote: > > > > > > > > > Thank you! Permissions granted. > > > > > > > > > > Ed > > > > > > > > > > On Mon, Jan 14, 2019 at 10:33 AM David Yahalomi <[email protected] > > > > > > wrote: > > > > > > > > > > > Thanks Ed! > > > > > > > > > > > > My confluence ID is davidyaha. > > > > > > > > > > > > Best, > > > > > > David > > > > > > ᐧ > > > > > > > > > > > > On Mon, Jan 14, 2019 at 7:51 PM Ed Cable <[email protected]> > > wrote: > > > > > > > > > > > > > Hi David, > > > > > > > > > > > > > > Sorry for the delayed reply. I for some reason did not see your > > > email > > > > > > till > > > > > > > now. Thank you very much for weighing in and volunteering to > > > > document a > > > > > > > threats list. I too believe that is a good starting point and > we > > > > might > > > > > > soon > > > > > > > have some others weighing in with their thoughts on the proper > > > > > > > architectural design. > > > > > > > > > > > > > > Sharing your knowledge in a both architecting a secure design > in > > > > which > > > > > > to > > > > > > > connect via client/self-service A{Is as well as your > > > recommendations > > > > on > > > > > > > deployment architecture are gladly appreciated. > > > > > > > > > > > > > > If you can share with me your confluence ID for the fineract > > > > > confluence, > > > > > > I > > > > > > > will give you the proper permissions so you can create the > > > suggested > > > > > > page. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Ed > > > > > > > > > > > > > > On Sun, Jan 6, 2019 at 2:34 AM David Yahalomi < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > Hello Fineracters, > > > > > > > > > > > > > > > > *TL;DR*: Let's start with a threats list and discuss each > > threat > > > on > > > > > > it's > > > > > > > > own and in composition. > > > > > > > > > > > > > > > > I'm David from Articode and I've recently started setting up > a > > > self > > > > > > > service > > > > > > > > fineract solution. > > > > > > > > In the past I've worked on developing a digital self service > > > branch > > > > > for > > > > > > > the > > > > > > > > 2nd biggest bank in Israel. Their core used T24 by the swiss > > > > company > > > > > > > > Temenos. > > > > > > > > I have recently been in contact with Ed and Fiter from the > > > fineract > > > > > > > > community, and I was asked by Ed to chime in this thread. > > > > > > > > > > > > > > > > In my experience, making a secure self service mobile > > application > > > > has > > > > > > > many > > > > > > > > concerns and requirements but most of those are addressed in > > > > > deployment > > > > > > > > architecture and the creation of a good audit and session > > > > management > > > > > > > tool. > > > > > > > > > > > > > > > > Is there a documented list of possible threats in having a > self > > > > > service > > > > > > > > mobile app? > > > > > > > > > > > > > > > > If not, I think it will be a great first step. I would gladly > > > start > > > > > one > > > > > > > on > > > > > > > > the confluence. > > > > > > > > Once curated, we can introduce various solutions to defend > > > against > > > > > any > > > > > > of > > > > > > > > those threats in various environments, but I think that the > > list > > > > is a > > > > > > > > mandatory step. > > > > > > > > > > > > > > > > Best, > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > *Ed Cable* > > > > > > > President/CEO, Mifos Initiative > > > > > > > [email protected] | Skype: edcable | Mobile: +1.484.477.8649 > > > > > > > > > > > > > > *Collectively Creating a World of 3 Billion Maries | * > > > > http://mifos.org > > > > > > > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > *Ed Cable* > > > > > President/CEO, Mifos Initiative > > > > > [email protected] | Skype: edcable | Mobile: +1.484.477.8649 > > > > > > > > > > *Collectively Creating a World of 3 Billion Maries | * > > http://mifos.org > > > > > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > > > > > > > > > > > > > > > > -- > > Sent from my iPad > > >
