Hey, I have an interesting idea to protect this resource from malicious attacks. We should definitely not expose these API for general Auth.
Here is the abstract we are implementing the crypto library for such Auth This is a piece of abstract we were going to submit to the Apache Con , now we are planning to release this as a general purpose crypto libs. In this digital day and age, passwords are no longer adequate. Users worldwide are victims of multiple malfeasances like brute force attacks, injection attacks, phishing, unsafe credentials, data theft, among others. The benefits of using passwords - which have increasingly become predictable, leave users vulnerable to data and identity theft. Even the strongest passwords are easy to crack and prone to phishing nonetheless. Hence, given all these nuisances, there’s a need to eliminate character-based authentication protocols, which would ultimately benefit all developers as well as end-users. To replace this conventional but antiquated protocol with a secure alternative, would be Passwordless Authentication. BitRupee is a secure passwordless authentication protocol that uses cryptography where one’s identity is presented with anonymity. This type of multi-factor authentication layer approves a sign in only after two or more verification factors (that are secured with a cryptographic key pair) are authorized. The BitRupee system is decentralized and only stores a public key in the database. The system creates a public and private key, of which the user is only able to access the private key. Further after signing the key, the user sends the information over the API to the server, where it checks its validity with the public key and grants access accordingly. We have already implemented this layer, we are porting this code to fineract . This API could be exchanged over the person who has access to private keys. Let me know the thoughts. On Thu, Jul 16, 2020 at 1:14 PM David Yahalomi <da...@articode.co> wrote: > Hey Michael, > > You are absolutely correct. The deployment details are crucial. For > offering a production-ready environment going with hosted managed DB on a > known cloud provider is a must IMO. Our FaaS tool uses the most basic > deployment (to keep costs down) - single EC2 instance on AWS that holds > both the Tomcat web server that provides Fineract and a local MySQL server > process that holds all the tenant DBs. As you suggested, we've created a > new Tenant Management Java Resource that just does "create database" and > then runs the migration files on that new tenant. As I said, it works as a > "default" tenant API so authentication is done using Basic auth with a > system user from that tenant. > Do you think that's adequate? > > Regarding the connection pool - we hadn't gone and tackled that one yet so > it might just be the connection pool configuration that needs to be > changed, but as far as I have seen, each tenant has it's own pool or at > least it seems this way when you look for open connections on the > MySQL server. > > David Yahalomi > Co-Founder > > Rothschild Blvd 3, Tel Aviv-Yafo, Israel > mobile: + 972 52 817 9787 > email: da...@articode.co > <https://articode.co> > > ᐧ > > On Thu, Jul 16, 2020 at 2:04 AM Michael Vorburger <m...@vorburger.ch> > wrote: > >> On Wed, 15 Jul 2020, 10:02 David Yahalomi, <da...@articode.co> wrote: >> >>> Hey Jubha and Awasum! >>> >>> We've created FaaS (Fineract as a service) <https://faas.articode.co/> >>> and part of that was automating the creation of new tenants. Our service is >>> public and meant for development purposes so the API to create new tenants >>> did not include any security considerations. >>> That being said, the front end site does not send requests directly to >>> Fineract but rather goes through an AWS lambda function (that could >>> potentially check for permissions/credits and whatnot) and it handles >>> calling Fineract. >>> >> >>> We have created a system user on the "default" tenant and it is used to >>> authenticate against this new "create tenant" API. >>> We would love to contribute this process if we could figure out a way to >>> deliver that functionality without too many moving parts. ideally, the >>> current Fineract server should handle the whole process on its own. >>> >> >> The crux I think is that creating an additional DB for a new Tenant is >> somewhat dependent on the details of the actual deployment... >> >> How do you create a new Tenant DB? Just SQL "create database newtenant;", >> OR using an API of a managed database by your favorite Cloud provider? >> (E.g. https://www.fineract.dev uses https://cloud.google.com/sql, but >> YMMV, fair enough.) >> >> But anyone motivated to do this sure could still make a start with >> contributing a Pull Request that adds a new Tenant Management Java Resource >> class eyc. for API which, for now, does the SQL (and that could later be >> extended for specific managed DBs in cloud). Go for it! >> >> Another consideration is scaling of such a setup. At the moment, Fineract >>> handles each tenant with it's own DB connection. That means that many >>> resources are allocated at the booting stage of Fineract server but >>> potentially never used (on less active tenants). This is something that we >>> should potentially figure out before offering production-grade deployment >>> of Fineract as a service. >>> >> >> I'm not sure I understand what exactly you mean here (just set the >> connection pool configuration appropriately, no?), but Pull Requests with >> any suggested Improvements to connection handling are always welcome, of >> course. >> >> Best, >>> >>> David Yahalomi >>> Co-Founder >>> >>> Rothschild Blvd 3, Tel Aviv-Yafo, Israel >>> mobile: + 972 52 817 9787 >>> email: da...@articode.co >>> <https://articode.co> >>> >>> ᐧ >>> >>> On Wed, Jul 15, 2020 at 10:27 AM jubha mayala <basston...@gmail.com> >>> wrote: >>> >>>> Hi All, I do not remember the name, but some guys from Israel have done >>>> this kind of thing. And they shared here the demo for people to have a look >>>> and test. anybody remembers this please point out their name. >>>> >>>> On Wed, Jul 8, 2020 at 7:08 PM Saransh Sharma <sara...@muellners.org> >>>> wrote: >>>> >>>>> Definitely, this could be a bonus if we could do the same for fineract >>>>> cn. >>>>> >>>>> Some thoughts, >>>>> >>>>> Super user can only or special right with 2fa API access. >>>>> >>>>> No delete option >>>>> >>>>> We can use db to be loaded as a service where , flyway migration >>>>> happens real time. >>>>> >>>>> Let me know what you think >>>>> >>>>> >>>>> >>>>> On Wed, 8 Jul 2020, 19:25 Awasum Yannick, <awa...@apache.org> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I think it will be a good idea to automate the process of creating >>>>>> and managing new tenants (DBs) on Fineract 1.x. At the moment, this is >>>>>> done >>>>>> via manual process and scripts as seen here: >>>>>> https://mifosforge.jira.com/wiki/spaces/docs/pages/187498786/How+to+Setup+New+Trail+Instance >>>>>> >>>>>> Will it be a good idea to automate this process so that each new >>>>>> tenant is created using say, an API endpoint? Maybe this endpoint will >>>>>> need >>>>>> to be protected (secure) so that not anyone can create a new tenant? How >>>>>> do >>>>>> we secure this process? >>>>>> >>>>>> >>>>>> Any thoughts? Are there people who have done things like this before? >>>>>> and might want to contribute back? >>>>>> >>>>>> I created an issue for this: >>>>>> https://issues.apache.org/jira/browse/FINERACT-1081 >>>>>> >>>>>> >>>>>> Thanks. >>>>>> Awasum >>>>>> >>>>> Mifos-developer mailing list >>>>> mifos-develo...@lists.sourceforge.net >>>>> Unsubscribe or change settings at: >>>>> https://lists.sourceforge.net/lists/listinfo/mifos-developer >>>> >>>> -- Thanks and regards, Saransh Sharma Research Partner This mail is governed by Muellners® IT policy. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
