Hi James, I reviewed the Fineract CN source based on your suggestion. A few things caught my attention. The identity separation approach in fineract-cn-identity aligns well with what the BFF needs, which is a user store that doesn't interact with the monolith's appuser model. Another point is about the scope: CN aimed for a complete microservice breakdown of the platform. This complexity made it genuinely difficult for new contributors to get started. In contrast, the BFF is designed to be simpler — just one service, one integration point. I also noticed that CN had some authentication design issues that were identified but never fixed before the project was discontinued. It's important to remember these as design constraints instead of merely historical notes. Regarding the event stream, I saw your reply to Edward and understand your doubts. The use case I have in mind is more specific than the accounting and data warehouse consumers you mentioned. I'm thinking about store-and-forward borrower notifications in low-connectivity markets, using Fineract's existing business event bus instead of creating a separate notification system. I noticed the codebase already implements this pattern for SMS and email campaigns. Whether this fits the POC scope is an open question for me — I'd rather know early. I have one operational question I haven't sorted out: when the BFF connects with Fineract using a service account, should the institution's admin set up that account manually before deployment, or would it make more sense to have a self-provisioning step during the first startup for a POC context? I'm putting together a brief architecture outline for FINERACT-2439 and would appreciate any feedback.
On 2026/03/06 20:57:26 James Dailey 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 > > > > > > > > > >
