osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <mage@xxxxxxxxxx> 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 <edcable@xxxxxxxxx> 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 <sendoro@singo.africa>
> > wrote:
> >
> > > My comments below is related to item no.2 not 3
> > >
> > > ----- Original Message -----
> > > From: "Sendoro Juma" <sendoro@singo.africa>
> > > To: "dev" <dev@xxxxxxxxxxxxxxxxxxx>
> > > Cc: "mifos-developer" <mifos-developer@xxxxxxxxxxxxxxxxxxxxx>
> > > 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" <edcable@xxxxxxxxx>
> > > To: "dev" <dev@xxxxxxxxxxxxxxxxxxx>
> > > Cc: "mifos-developer" <mifos-developer@xxxxxxxxxxxxxxxxxxxxx>
> > > 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 <edcable@xxxxxxxxx> 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 ( Example, Bengaluru has P1 and P2 products where as
> > jaipur
> > > >    has P2 and P3 products )
> > > >    - Based on customer work profile ( for salaried person offer
> > personal
> > > >    loans, for business person offer working capital )
> > > >    - based gander, income etc
> > > >
> > > > UC 2. User management, (In Rupie's case they have around six thousand
> > > self
> > > >  service users, need effective user management suite, search user,
> user
> > > > activity tracking etc)
> > > > - So user management has to be a lot more robust than user management
> > > from
> > > > the perspective of staff users.
> > > > UC 3.  Push ad-hoc/rule based/event based notification to users
> > > >
> > > > Ed
> > > >
> > > > On Tue, Jan 16, 2018 at 11:58 AM, Markus Geiss <mage@xxxxxxxxxx>
> > wrote:
> > > >
> > > >> Dear Ed,
> > > >>
> > > >> We at Kuelap have no plans because believe we should never give
> > members,
> > > >> agents, or other third parties direct access to the financial
> > > >> institution's
> > > >> data.
> > > >> Aside from any regulatory standpoint this is a huge flaw in the
> > current
> > > >> system.
> > > >>
> > > >> My company is working on two offline-first clients that we think are
> > > more
> > > >> secure
> > > >> architecture; one will provide a reduced set of functionalities for
> > > >> employees
> > > >> working in remote areas; The second one will provide mobile banking
> > > >> functionalities for members of financial institutions.
> > > >>
> > > >> Once the company feels the time is right to share our work, we may
> > > propose
> > > >> these apps or at least the secure architecture to the community, but
> > we
> > > >> are
> > > >> not nearly far enough along to do that now.
> > > >>
> > > >> Cheers
> > > >>
> > > >> Markus
> > > >>
> > > >> .::Yagni likes a DRY KISS::.
> > > >>
> > > >>
> > > >> On Tue, Jan 16, 2018 at 3:54 PM Ed Cable <edcable@xxxxxxxxx> wrote:
> > > >>
> > > >> > Markus, Mark or others who could best respond,
> > > >> >
> > > >> > What is the planned design for enabling third parties (i.e.
> > non-staff)
> > > >> such
> > > >> > as clients, agents, etc to authenticate themselves and access data
> > > >> within
> > > >> > Apache Fineract CN.
> > > >> >
> > > >> > From what I recalled, you were planning to take a more secure
> > approach
> > > >> than
> > > >> > simply providing a self-service API that has access to the full
> > > >> production
> > > >> > database but rather have a separate data layer for self-service
> > users?
> > > >> >
> > > >> > Could you update the community on what the plans are for providing
> > > >> access
> > > >> > to enable these client-facing applications? Is it documented
> > anywhere?
> > > >> >
> > > >> > One reason I ask is it that as the Mifos Initiative thinks about
> > GSOC
> > > >> 2018,
> > > >> > I'd like to consider a project on building out an initial mobile
> > > banking
> > > >> > app on top of Apache Fineract CN.
> > > >> >
> > > >> > Thanks,
> > > >> >
> > > >> > Ed
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > *Ed Cable*
> > > > President/CEO, Mifos Initiative
> > > > edcable@xxxxxxxxx | Skype: edcable | Mobile: +1.484.477.8649
> > > > <(484)%20477-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
> > > edcable@xxxxxxxxx | 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
> > edcable@xxxxxxxxx | 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
edcable@xxxxxxxxx | 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>