Edward - inline
On Fri, Mar 6, 2026 at 1:37 PM Edward Kang <[email protected]> wrote: > Thanks for the insightful discussion Ashar and James! I'll be sure to read > about the fineract-CN project as well to see what the pros and cons of its > architectural design were. > > @James on your post, can I ask what feature completeness looks like for a > project, and what the requirements are for an Apache release (ie. security, > unique extra features, project completeness like having CI/CD, > documentation, testing, etc)? > For a release to be valid candidate for a release, sure, it should abide by norms like being secure by design, having a reproducible build, and it should "run." That is, it cannot just be code - it has to "do something". The minimum is thus a pretty low bar, but generally projects try to release "their best work" because that's what generates more interest. A project release requires a PMC vote of yes. (Consensus doesn't mean unanimous consent.) > Also, a little unrelated but I am thinking through how the BFF would > interact with Fineract for some systems. My question is whether we can > utilize features of Fineract that are behind configuration flags like the > external event systems (ActiveMQ/Kafka). Should we design around using > those or not, in your opinion? > Well, you've reached an area of ambiguity for me. I guess it will depend on the use cases you think are needed in a POC. I doubt we need the event stream for a front end, but perhaps it's easier than a specific data query. ? Notionally, I don't think I like it. The consumers of event data are usually other accounting systems, data warehouses, or other third party systems that rely on the events for triggering (e.g. post processing fraud detection). > > > > On Fri, Mar 6, 2026 at 2:57 PM James Dailey <[email protected]> > wrote: > >> You should check the dev email archives for the history of the >> fineract-CN project. (cloud native) >> There are also wiki pages marked "deprecated" about it. >> >> TL;DR: Not enough developers were interested in the new approach. It was >> a good design, but it never achieved 100% feature completeness. >> Since no one was willing to develop it further, and we couldn't achieve a >> formal release (a key requirement at Apache), we retired the project. >> It was a good prototype exercise at a minimum. Borrowing from the design >> concepts is a good idea. >> >> The lesson is that projects need engaged constituencies. >> >> James Dailey >> >> >> >> On Fri, Mar 6, 2026 at 9:07 AM Ashhar Ahmad Khan <[email protected]> >> wrote: >> >>> Hi James, >>> >>> That clarifies the direction. >>> >>> Keeping the BFF responsible for end-user identity and calling Fineract >>> through a service account seems like the clean boundary. >>> >>> I'll go through Fineract CN carefully. Since it never reached adoption, >>> I want to understand what prevented it before applying ideas from it to the >>> POC. >>> >>> Ashhar >>> >>> >>> >>> >>> On 2026/03/05 18:23:47 James Dailey wrote: >>> > Speaking for myself.... my idea with creating this ticket is that the >>> BFF >>> > should have its own authorization server and a user database separate >>> from >>> > the fineract user. That implies some design decisions that the GSOC >>> > student should try to resolve as part of the project. Maybe you have >>> ideas >>> > we haven't considered. >>> > >>> > To be clear - the BFF is for the END-USER (customer or client), not the >>> > user in the system (back office user). >>> > >>> > Unless and until fineract has implemented ABAC (attribute based access >>> > control) in addition to the the built in RBAC (role based access >>> control), >>> > this external end-user database pattern is likely the preferred path. >>> > There are other efforts to figure out this problem and I do not mean to >>> > step on those toes. However, when Fineract removed the Self-Service >>> APIs >>> > from our release, we deliberately removed the pattern that created >>> > potential security vulnerabilities, which also removed an important >>> area of >>> > functionality. This POC should not re-introduce those concerns. >>> > >>> > Since this is a proof of concept (POC) and not intended for >>> production, we >>> > want to clarify that it represents a usable pattern or one that could >>> lead >>> > to future architectural changes or work. A POC should allow for >>> > exploration of the solution space with a relatively small investment in >>> > time and effort (small being relative to teams of people working over >>> many >>> > months or years). >>> > >>> > An advantage of working on a separate component here is that it can >>> enable >>> > forward progress without changes to Fineract. This separation of >>> concerns >>> > is an advantage. You may want to examine the previously designed but >>> > abandoned fineract-CN project which included this separation. >>> > >>> > On Thu, Mar 5, 2026 at 1:03 AM Edward Kang <[email protected]> wrote: >>> > >>> > > Hi Ashar, thanks for the comment in the Matrix chat. As you know, I >>> am >>> > > working on this proposal as well for GSoC 2026. I'm leaning towards >>> keeping >>> > > the BFF's auth layer separate from Fineract's OAuth2, but it's a good >>> > > question for the mentors. Looking forward to discussing it with them! >>> > > >>> > > Best, >>> > > Edward >>> > > >>> > > On Wed, Mar 4, 2026 at 12:25 PM Ashhar Ahmad Khan <[email protected]> >>> > > wrote: >>> > > >>> > >> Hi everyone, >>> > >> >>> > >> While thinking through the BFF auth design for FINERACT-2439, I >>> noticed >>> > >> that FINERACT-1984 is already marked Fixed targeting 1.13.0 - >>> meaning the >>> > >> develop branch now ships with Spring Authorization Server built in >>> and >>> > >> Fineract can act as its own OAuth 2.1 authorization server. >>> > >> >>> > >> That changes the BFF auth question a bit. The way I see it there >>> are two >>> > >> directions: the BFF registers itself as an OAuth client against >>> Fineract's >>> > >> own authorization server, or it keeps a completely separate >>> identity layer >>> > >> and calls Fineract purely as a downstream resource server using a >>> dedicated >>> > >> service account. The first is simpler but it ties consumer auth to >>> > >> Fineract's m_appuser model - which is exactly what the old >>> self-service >>> > >> module did wrong. The second keeps the boundary clean but means >>> running two >>> > >> auth layers. >>> > >> >>> > >> Is there a preferred direction here, or is this one of the open >>> design >>> > >> questions the POC is meant to explore? >>> > >> >>> > > >>> > > >>> > > -- >>> > > Edward E. Kang >>> > > [email protected] >>> > > 972-768-6940 >>> > > >>> > >>> >> > > -- > Edward E. Kang > [email protected] > 972-768-6940 >
