Thanks Petri - On Fri, Apr 21, 2023 at 6:24 PM Petri Tuomola <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> 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> 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> >> wrote: >> >>> +1 for keycloack >>> >>> On Fri, Apr 21, 2023, 11:47 PM Aleksandar Vidakovic < >>> 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). 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 > > >
