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