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 > > > > > >
