search

hyperledger-labs / business-partner-agent

The Business Partner Agent is a SSI wallet and controller based on aries cloud agent python.
https://labs.hyperledger.org/business-partner-agent/
Apache License 2.0
56 stars 49 forks source link

Support Multi Tenancy #558

Open etschelp opened 3 years ago

etschelp commented 3 years ago

As this topics tends to pop up in various discussions I started to write down some thoughts on what changes are needed in the BPA to make this happen if we want to.

https://hackmd.io/@AN7LHuEORQSPrOdHz3SrEA/BJ9Fb4vR_

swcurran commented 3 years ago

@amanji and @esune -- please take a look at this, given your experience. Haven't looked yet, but need to be sure that the endorser capabilities are covered. That is likely needed in BPA with/without agency design.

esune commented 3 years ago

I don't have access to the HackMD document, getting a 403 error.

etschelp commented 3 years ago

I updated the URL, its public now

esune commented 3 years ago

I looked at the document, looks good to me. There is no mention of endorsing transactions though: @etschelp let me know if you need an overview of how that works and what type of workflows and other services you would need to setup and orchestrate.

The other thing I added a comment for in the document is that each tenant will require BOTH the agency admin-api-key AND their token to operate. This is not great in my opinion, and needs to be abstracted so that tenants only need to deal with one key. We have added a "proxy" that hands out generated api-keys and binds them to a tenant's token, and builds the right request internally when needed in order to not hand out the main admin key to everyone.

A goo resource to poke at is aries-vcr-issuer-agency as we have implemented all of the above (one interpretation of it, at least).

frank-bee commented 3 years ago

Great that you started with a document, @etschelp Maybe we need a chapter at the beginning of the document what we want to achieve. For me it is still not clear. If it is just about resource consumption of a potential BPA SaaS solution, I would phrase also the Issue like this. In this case we really need numbers : How many BPAs do we need in a SaaS solution? How much resources ( RAM / CPU) does a BPA really need minimally? Is the Java overhead of the backend really that big that we need to get rid of our microservice architecture?

Maybe - if at all - it is enough to allow multiple tenants on "one big acapy" ( the database would be anyway hosted in a DBM and not in a single pod like now in the default config of the our chart)?

Don't get me wrong. It is really good to have an overview about potential technical hurdles to switch from micro services to silos. But asking the question if we need that I find crucial.