Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
+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 "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 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 < > vish...@confluxtechnologies.com> 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 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 < > > > vish...@confluxtechnologies.com> 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.
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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 < vish...@confluxtechnologies.com> 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 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 < > > vish...@confluxtechnologies.com> 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
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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 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 < > vish...@confluxtechnologies.com> 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
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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 < vish...@confluxtechnologies.com> 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
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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 wrote: > Thank you! Permissions granted. > > Ed > > On Mon, Jan 14, 2019 at 10:33 AM David Yahalomi
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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 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
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
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
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
Hi Markus, Thanks for sharing this insight on the list. I will pass this on to the teams that are going to start doing some work with some external front-ends and will make sure they ask questions and interact with you on-list. Ed On Mon, Dec 3, 2018 at 6:43 AM Markus Geiss wrote: > Hey Fineracters, > > we have chosen to use a clean and clear separation of concerns. This mean > we will use separate data stores and services from the back office to serve > front office/client facing apps. This also includes separate user > management > for those apps and a special API user to sync between both solutions. > > Depending on the use case we are going to use an offline-first solution > based on on CouchDB/PouchDB to synchronize data to the devices, > or offer a specialized service for real time processing. If the former is > used we are going to use CouchDB sync gateway to keep the data > back and front office services in sync. > > In both cases there will be a sort of mediator service to sync data between > the separated front the back office services. For this we are using > both integrations, direct API access and event based messaging. > > Given Fineract CN already comes with Active MQ it is simple to integrate > any type of foreign component via the build in pub/sub model. > > Cheers > > Markus > > .:: YAGNI likes a DRY KISS ::. > > > On Fri, Nov 30, 2018 at 2:35 PM Ed Cable wrote: > > > Markus and others, > > > > I wanted to bring this back to top of mind. There are a number of efforts > > in the community moving forward where external, client-facing apps might > > soon be moving into actual production usage. Discussion on this thread > > should be valuable happening in parallel to the thread that James started > > on architecture/design for payments integration via Mojaloop. > > > > Markus - at this point, are you able to share what secure > > architecture/design pattern you all chose in which to implement external > > apps that is secure and not giving direct access to the financial > > institution's data. > > > > For the community at large, especially those with deep experience > > implementing these systems, we welcome your valuable input to help get > this > > right for Fineract CN. > > > > Ed > > > > On Tue, Mar 20, 2018 at 11:26 PM Sendoro Juma > > wrote: > > > > > My comments below is related to item no.2 not 3 > > > > > > - Original Message - > > > From: "Sendoro Juma" > > > To: "dev" > > > Cc: "mifos-developer" > > > Sent: Wednesday, March 21, 2018 8:07:34 AM > > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache > > Fineract > > > CN > > > > > > Hello Ed, Dev > > > > > > On item no. 3 on registration verification > > > > > > I think mobile phone verification is even more important than email > > > nowadays, so it can be both email and phone.. it should be added and I > > > suggest to be a MUST. > > > > > > Regards > > > Sendoro > > > > > > - Original Message - > > > From: "Ed Cable" > > > To: "dev" > > > Cc: "mifos-developer" > > > Sent: Wednesday, March 21, 2018 5:40:22 AM > > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache > > Fineract > > > CN > > > > > > Hi all, > > > > > > As a follow-up to this thread, Sundari has fleshed out some more > details > > > supporting the use cases Nayan had proposed for a client-facing digital > > > credit app at > > > > > > > https://cwiki.apache.org/confluence/display/FINERACT/Digital+Credit+App > > > > > > Markus, Myrle, or others - it'd be great to get your input as to how > > you'd > > > securely enable clients to access the data needed in such an app. > > > > > > Ed > > > > > > On Fri, Jan 26, 2018 at 6:20 PM, Ed Cable wrote: > > > > > > > Hi Markus, > > > > > > > > Thanks for your replies. > > > > > > > > For the rest of the community, > > > > > > > > While I know that with the previous iteration of self-service apps, > we > > > > focused on implementing the back-end first and then allowing > front-end > > > use > > > > cases to follow, a good approach this time around would be to get > some > > > > solid client-facing use cases identified and then design the back-end > > and > > > > integration with the data to support those use cases. Nayan from > RuPie > > > has > > > > shared some initial use cases he has. I'm working with a Mifos > > volunteer, > > > > Sundari Swami, to flesh these out further but wanted to share the > > initial > > > > use cases Nayan had presented to stimulate further discussion on what > > the > > > > best approach to supporting a client-facing app on Apache Fineract CN > > > that > > > > would support adequately: > > > > > > > > From customer side > > > > > > > > UC 1. Client signup with basic data, and spot verification either > with > > > OTP > > > > to mobile number or Aadhaar verification > > > > UC 2. Customer can enter customer's other details like address, > family, > > > > work, income/expense details, once this data is verified from back > > > office, >
Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN
Hey Fineracters, we have chosen to use a clean and clear separation of concerns. This mean we will use separate data stores and services from the back office to serve front office/client facing apps. This also includes separate user management for those apps and a special API user to sync between both solutions. Depending on the use case we are going to use an offline-first solution based on on CouchDB/PouchDB to synchronize data to the devices, or offer a specialized service for real time processing. If the former is used we are going to use CouchDB sync gateway to keep the data back and front office services in sync. In both cases there will be a sort of mediator service to sync data between the separated front the back office services. For this we are using both integrations, direct API access and event based messaging. Given Fineract CN already comes with Active MQ it is simple to integrate any type of foreign component via the build in pub/sub model. Cheers Markus .:: YAGNI likes a DRY KISS ::. On Fri, Nov 30, 2018 at 2:35 PM Ed Cable wrote: > Markus and others, > > I wanted to bring this back to top of mind. There are a number of efforts > in the community moving forward where external, client-facing apps might > soon be moving into actual production usage. Discussion on this thread > should be valuable happening in parallel to the thread that James started > on architecture/design for payments integration via Mojaloop. > > Markus - at this point, are you able to share what secure > architecture/design pattern you all chose in which to implement external > apps that is secure and not giving direct access to the financial > institution's data. > > For the community at large, especially those with deep experience > implementing these systems, we welcome your valuable input to help get this > right for Fineract CN. > > Ed > > On Tue, Mar 20, 2018 at 11:26 PM Sendoro Juma > wrote: > > > My comments below is related to item no.2 not 3 > > > > - Original Message - > > From: "Sendoro Juma" > > To: "dev" > > Cc: "mifos-developer" > > Sent: Wednesday, March 21, 2018 8:07:34 AM > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache > Fineract > > CN > > > > Hello Ed, Dev > > > > On item no. 3 on registration verification > > > > I think mobile phone verification is even more important than email > > nowadays, so it can be both email and phone.. it should be added and I > > suggest to be a MUST. > > > > Regards > > Sendoro > > > > - Original Message - > > From: "Ed Cable" > > To: "dev" > > Cc: "mifos-developer" > > Sent: Wednesday, March 21, 2018 5:40:22 AM > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache > Fineract > > CN > > > > Hi all, > > > > As a follow-up to this thread, Sundari has fleshed out some more details > > supporting the use cases Nayan had proposed for a client-facing digital > > credit app at > > > > https://cwiki.apache.org/confluence/display/FINERACT/Digital+Credit+App > > > > Markus, Myrle, or others - it'd be great to get your input as to how > you'd > > securely enable clients to access the data needed in such an app. > > > > Ed > > > > On Fri, Jan 26, 2018 at 6:20 PM, Ed Cable wrote: > > > > > Hi Markus, > > > > > > Thanks for your replies. > > > > > > For the rest of the community, > > > > > > While I know that with the previous iteration of self-service apps, we > > > focused on implementing the back-end first and then allowing front-end > > use > > > cases to follow, a good approach this time around would be to get some > > > solid client-facing use cases identified and then design the back-end > and > > > integration with the data to support those use cases. Nayan from RuPie > > has > > > shared some initial use cases he has. I'm working with a Mifos > volunteer, > > > Sundari Swami, to flesh these out further but wanted to share the > initial > > > use cases Nayan had presented to stimulate further discussion on what > the > > > best approach to supporting a client-facing app on Apache Fineract CN > > that > > > would support adequately: > > > > > > From customer side > > > > > > UC 1. Client signup with basic data, and spot verification either with > > OTP > > > to mobile number or Aadhaar verification > > > UC 2. Customer can enter customer's other details like address, family, > > > work, income/expense details, once this data is verified from back > > office, > > > customer can't edit any of these data > > > UC 3. Apply for loans > > > UC 4. Repay EMI > > > UC 5. Preclose his/her loans > > > UC 6. Log support request > > > UC 7. Upload documents like photo of electricity bills, voter id, > > passport > > > etc, once documents are verified and accepted from back office customer > > > cab't edit , delete the verified documents, but customer can upload new > > > documents > > > > > > From organization point of view > > > > > > UC 1, Offer loan products based below criteria > > > > > > > > >- Location (
