Some of these ideas should be part of the proposal and back and forth with a mentor. I will not be the primary mentor on this. See matrix and ask there.
On Sun, Mar 8, 2026 at 8:26 AM Ashhar Ahmad Khan <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
