On Thu, Jul 16, 2020 at 1:09 PM Saransh Sharma <[email protected]> wrote:
> 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 <[email protected]> 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? >> > With Saransh's ideas for future authentication a much bigger topic, i think protecting this resource with Fineract's existing built-in current authentication and authorization (through a new role) is perfectly adequate, to start this. A Pull Request from you proposing adding a new Tenant Management Java Resource that just does "create database" and then runs the migration files on that new tenant would be a great contribution! We eagerly await it being able to review it... ;-) 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: [email protected] >> <https://articode.co> >> >> ᐧ >> >> On Thu, Jul 16, 2020 at 2:04 AM Michael Vorburger <[email protected]> >> wrote: >> >>> On Wed, 15 Jul 2020, 10:02 David Yahalomi, <[email protected]> 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: [email protected] >>>> <https://articode.co> >>>> >>>> ᐧ >>>> >>>> On Wed, Jul 15, 2020 at 10:27 AM jubha mayala <[email protected]> >>>> 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 <[email protected]> >>>>> 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, <[email protected]> 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 >>>>>> [email protected] >>>>>> 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. >
