Hi James To me the question about removing basicauth is: does it actually make things safer?
No one should be using basicauth in production anyway. And if no one is using basicauth in production, then by removing it we make developers life harder without making production any safer. I’m sure we all want to keep the “barrier to entry” to Fineract for new developers / contributors as low as possible. Maybe as a compromise we could just add a lot of logging into basicauth module so that every time it is used it logs something like “UNSAFE - NOT FOR PRODUCTION USE”? Then at least people would not accidentally use it on production systems. Though if you are accidentally using basicauth in production, you’re probably prone to some other serious mistakes as well (e.g. using default passwords, not enforcing https etc). And we clearly can’t safeguard against every possible mistake. Just some thoughts... Regards Petri > On 25 Apr 2023, at 6:25 AM, James Dailey <jamespdai...@gmail.com> wrote: > > Thanks Petri - > > On Fri, Apr 21, 2023 at 6:24 PM Petri Tuomola <petri.tuom...@gmail.com > <mailto:petri.tuom...@gmail.com>> wrote: >> Hi >> >> I think there’s a bit of confusion here - allow me to share some comments >> (and apologies for trivialising this for those who know much more about this >> than I do): >> >> - For OAuth there are two components - the actual OAuth authorisation server >> and the application using OAuth to authenticate (confusingly called resource >> server) >> >> - Spring Security used to provide both authorisation server and a resource >> server, and we were using both in Fineract >> >> - Nowadays Spring Security just provides the resource server (i.e. the code >> used by an application to integrate with an OAuth authorisation server) so I >> reworked the code to remove the authorisation server when I upgraded >> Fineract to the latest version of Spring Security >> >> - At the same time, I tested this with a couple of different authorisation >> servers - including Keycloak - and included in the documentation the >> configuration settings and instructions on how to get Fineract working with >> Keycloak >> >> - As far as I know, we’re only using Oltu for the Fineract Client SDK - the >> server side is only Spring Security (at least was when I worked on it) >> >> - However as far as I recall we only use OAuth to determine if a user is >> valid - ie authentication. We don’t use it for authorisation (with some >> exceptions) >> >> Then to Aleks’s proposal… if I understood correctly that would mean: >> >> - Deprecating basicauth altogether. >> - Leveraging OAuth information for role authorisation >> >> The first one is easy to do but has the downside of making simple debugging >> / testing harder - you always need to have an OAuth2 server set up and >> available. But for the users using Docker, we could make this reasonably >> easy... > Is it reasonable to have a deprecated or demo "Basic Auth" infrastructure > kept around for the student doing a project? (I believe that you've said no, > but just confirming) > Deprecation makes it clear not to use in Production. > >> >> The second one is a bit more intrusive as it requires removing the whole >> role framework and replacing it with Spring Security annotations etc. I >> suppose for me the main question is: is the role framework there just for >> security, or is it there for business rules as well? If it’s for security >> (i.e. authorisation) then OAuth2 sounds like a good place for it. But if we >> have roles / role groups etc mainly for business reasons - and want to keep >> evolving this to support various business rules - then making it part of >> OAuth2 may limit what we are able to support in the future. > > Yes, this is where I am particularly concerned that we need more > understanding of the impacts. Fine grained controls are needed for work > flow, configuration of products, operations on data scope, etc. > >> >> Just my thoughts… happy to discuss >> >> Regards >> Petri >> >> >> >>> On 22 Apr 2023, at 8:51 AM, James Dailey <jamespdai...@gmail.com >>> <mailto:jamespdai...@gmail.com>> wrote: >>> >>> Thanks Aleksander - >>> >>> That’s a well laid out case. To play devil’s advocate, we’re already making >>> extensive use of Spring Boot and it intuitively make more sense to reduce >>> our dependency map. Why not Spring Security and server? >>> >>> https://docs.spring.io/spring-security/reference/servlet/oauth2/index.html >>> >>> I think you need to demonstrate why keycloak is better, not just now… but >>> as a long term strategy. And I think we need bit of a face off to pick the >>> right one, with some side by side comparisons. >>> >>> Secondly, this doesn’t sound like a drop in strategy. It instead sounds >>> like brain surgery of the kind that takes lots of cycles and introduces new >>> risks. Are there smaller proof of concept steps that could be done? (With >>> whatever is selected.) >>> >>> Question: would we hold up the next release until we get this proposed >>> project done ? >>> >>> Third, banking systems are often audited by regulators and various >>> compliance groups. It would behoove us to validate any new strategy before >>> implementing. >>> >>> Again, thanks for surfacing. >>> >>> James >>> >>> >>> On Fri, Apr 21, 2023 at 4:01 PM Willie Ng'ang'a Macharia >>> <ngangawilli...@gmail.com <mailto:ngangawilli...@gmail.com>> wrote: >>>> +1 for keycloak. >>>> >>>> I can help to implement Keycloak as we use it in my current role. >>>> >>>> Regards, >>>> >>>> Willie Macharia. >>>> >>>> >>>> On Sat, Apr 22, 2023 at 12:17 AM Muhammad El-Shafie <muham...@elshafie.me >>>> <mailto:muham...@elshafie.me>> wrote: >>>>> +1 for keycloack >>>>> >>>>> On Fri, Apr 21, 2023, 11:47 PM Aleksandar Vidakovic >>>>> <chee...@monkeysintown.com <mailto:chee...@monkeysintown.com>> wrote: >>>>>> Hi everyone, >>>>>> >>>>>> ... I'd like to make a suggestion to improve the security mechanics in >>>>>> Fineract. For the impatient first a... >>>>>> >>>>>> >>>>>> TL;DR: >>>>>> >>>>>> current security in Fineract: inflexible, liability, maintenance eating >>>>>> into our time budget, increasing number of CVEs expected >>>>>> >>>>>> vs >>>>>> >>>>>> third party OAuth integration: outsource all security related >>>>>> maintenance to another dedicated team/community (e. g. Keycloak), more >>>>>> robust implementation, more features (password hash functions, advanced >>>>>> user interfaces, 100% standard conform workflows), zero technical debt >>>>>> for Fineract, flexibility (LDAP, Active Directory, Social Media logins >>>>>> aka no passwords stored on our system) >>>>>> >>>>>> >>>>>> What we currently have is a straight forward implementation of role >>>>>> based access control (RBAC) using a relational database for storage. >>>>>> This implementation served us well in the past, but I think it's >>>>>> becoming a bit inflexible for integration in bigger enterprise >>>>>> architectures (read: LDAP/Active Directory, SSO...). Our default >>>>>> authentication scheme is still Basic Auth which - I think is safe to say >>>>>> - is not secure and absolutely not recommended for production. To >>>>>> address this issue we added an OAuth module and a 2FA module. Even those >>>>>> improvements start to have their own issues; e. g. our OAuth >>>>>> implementation is based on an Apache sister project called Oltu... >>>>>> which is unfortunately retired (read: end of life). We are even not able >>>>>> to use the latest 1.0.2 version, because it's incompatible with some of >>>>>> the other dependencies we have (I don't remember exactly, but it was >>>>>> probably related to OpenAPI). >>>>>> >>>>>> What I want to say is: I think in the long run we cannot win this race >>>>>> for up to date security and flexibility when integrating Fineract in 3rd >>>>>> party environments with existing security infrastructure. We are >>>>>> responsible for every piece of code we ship - and this includes all >>>>>> security related parts of course. I'm confident that our community would >>>>>> be capable to address any bugs or improvements around security, but we >>>>>> have to ask ourselves if "security" is what we do or if it's "finance". >>>>>> Don't get me wrong, of course Fineract needs to be secured... but my >>>>>> point is: are we the best to do it on top of everything else we do or >>>>>> can we delegate this to someone else and invest our time in and focus on >>>>>> improving Fineract's core features? >>>>>> >>>>>> I think that OAuth in particular is going to stay for a (long) while as >>>>>> the common denominator for everything concerning authentication, so... >>>>>> why not make this our default authentication scheme and ditch Basic Auth >>>>>> for good (why keep it when it's just potentially creating security >>>>>> concerns). Let's ignore for a moment the impact (read: code changes) >>>>>> such a decision would have and let's think for a moment how we could >>>>>> integrate such a feature in Fineract with minimal effort from our side >>>>>> and what benefit this would bring to the community. >>>>>> >>>>>> Spring Boot and Spring Security overhauled their OAuth integrations >>>>>> fairly recently. For a while this was a bit confusing. There were two >>>>>> competing OAuth implementations available and it was not really clear >>>>>> which one was the preferred way to use (at least not to me). >>>>>> >>>>>> There is a really simple way to get you going with OAuth authentication >>>>>> now ("OAuth client configuration"). I won't go into the details, but the >>>>>> new Spring Security libraries are supporting auto configuration and >>>>>> other Spring Boot conventions extensively and make the adjustments >>>>>> really trivial. Just a handful of entries in application.properties and >>>>>> you are pretty much done... if you use existing services (social media >>>>>> logins like Google, Facebook, Twitter...) and/or an existing OAuth >>>>>> identity server. >>>>>> >>>>>> There is a - kind of - identity server product available from Spring >>>>>> (https://spring.io/projects/spring-authorization-server); actually it's >>>>>> more like an embedded library that turns a Spring Boot instance into an >>>>>> OAuth server. This library offers everything you'd need to support the >>>>>> OAuth standard, but it's a minimal implementation. There is no user >>>>>> interface and the features cover the bare minimum you need to meet the >>>>>> OAuth requirements. And this solution requires at least some coding. >>>>>> >>>>>> Instead of Spring's Authorization server I'd suggest to use Keycloak >>>>>> (https://keycloak.io <https://keycloak.io/>). For those who don't know >>>>>> it: Keycloak is an >>>>>> open-source identity and access management solution that provides set of >>>>>> features for authentication and authorization. It has a robust security >>>>>> model with support for multiple authentication protocols, including >>>>>> OAuth 2.0 and OpenID Connect. Integrating with Keycloak allows you to >>>>>> take advantage of these protocols without having to implement them >>>>>> yourself. >>>>>> >>>>>> Keycloak would allow us to keep a similar centralized user management >>>>>> (supports various relational databases) with an advanced web UI (for >>>>>> configuration and user management)... if we really would want to keep >>>>>> the user data actually. We can also configure it to use other SSO/Social >>>>>> Media authentication providers which would relieve us from saving highly >>>>>> sensitive data in our databases: passwords. If we don't store it then we >>>>>> can't lose it. >>>>>> >>>>>> Other features we get with Keycloak basically for free: >>>>>> >>>>>> - we get proper 2FA for free (really works well with apps like Authy) >>>>>> - proper password resets >>>>>> - secure password policies >>>>>> >>>>>> Keycloak has a very active community that produces frequent >>>>>> releases/updates. We could benefit hugely from their ongoing development >>>>>> and maintenance. We could also tap into their security domain related >>>>>> knowledge pool. >>>>>> >>>>>> We could integrate Keycloak relatively easily (please take this as a >>>>>> placeholder; I think Keycloak would be a very good choice, but maybe >>>>>> there are other/better OS projects out there). >>>>>> >>>>>> Before we do anything I would suggest to analyze our current security >>>>>> mechanics and try to extract them as a separate (custom) module with >>>>>> 100% backwards compatibility. >>>>>> >>>>>> Once this is working we would create another (custom) module to make >>>>>> Keycloak a drop-in replacement for the legacy security mechanics. >>>>>> >>>>>> To get the authentication part in place you are pretty much done with 3 >>>>>> line of configuration in application.properties. Unfortunately we use >>>>>> the implementation of our homegrown security solution quite a bit in the >>>>>> code base. There are the classes AppUser and PlatformUserDetailsService >>>>>> that are pretty much directly tied to a relational databases. Especially >>>>>> AppUser is actually a JPA entity class and embedded/used in other entity >>>>>> classes (see Loan...). To avoid major refactorings we would need to >>>>>> create a bit of glue code that creates entries in the AppUser table with >>>>>> metadata taken from OAuth access tokens (I'm pretty sure that Spring >>>>>> Security OAuth fires internally some events that we can tap into and use >>>>>> to fill in missing data). Again: we would maintain AppUser only and fill >>>>>> it's database table to keep things working. >>>>>> >>>>>> Concerning authorization I could imagine that we need to do a bit more >>>>>> work. Again, we can figure this out later. I think it's possible to >>>>>> achieve this even without any reliance on legacy role tables etc. >>>>>> >>>>>> Technically this integration is pure OAuth and nothing Keycloak specific >>>>>> on our side... makes configuration of a different OAuth compliant >>>>>> identity server a minor effort... and involves usually no coding. >>>>>> >>>>>> Please add your comments and questions... there is also a Jira ticket >>>>>> with a bit more information >>>>>> (https://issues.apache.org/jira/browse/FINERACT-1908). >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Aleks >>>>>> >>>>>> >>> -- >>> Sent from Gmail Mobile
