On 22/04/2023 02:51, James Dailey 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
Valid point. In fact, you can consider Keycloak actually like a
placeholder... which OAuth compliant identity server (or 3rd party
service) we use is actually secondary... if the community decides that
going the "embedded library way" (read: Spring Authorization server)
then fine, but packaging it with Fineract it would mean that
Fineractwould be the identity server. I'd call this "all batteries
included approach". Sounds great for demo setups and maybe smaller orgs
using Fineract, but in fact we are limiting their choice again. The
Keycloak integration happens via configuration only and in fact there is
nothing Keycloak specific in that configuration. We could as well
configure any other compliant OAuth server
(https://www.libhunt.com/topic/oauth2-server; Keyloak is just one of
them) or 3rd party service
(https://en.wikipedia.org/wiki/List_of_OAuth_providers).
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.
Where Keycloak has an edge over Spring Authorization Server and others
(my 2 cents):
- Apache compatible license... because it's Apache licensed
(https://github.com/keycloak/keycloak-community/blob/main/LICENSE.txt)
- it's a Java project, we are a Java project... comes in handy if we
wanted to contribute one or the other extension
- the integration in Fineract is very easy (at least for authentication;
one dependency that is provided by Spring, 5 lines of configuration)
- Keycloak supports standards such as OAuth 2.0, OpenID Connect, SAML
2.0, LDAP, and Kerberos which means you can use it as a single source of
truth from your operating system/terminal authentication to securing
REST endpoints to securing environments like Kubernetes
- it's a Redhat project... which is a part of IBM... who has definitely
a stake in the finance and banking industry; I don't think they would
sponsor such a project and not use it
- Keycloak is a mature project: not pre-alpha, not pre-1.0, it exists
already for a couple of years
- there is a dedicated team and a healthy community to support the
project; e.g. Keycloak contributors = 868 vs Fineract contributors =
185; significant Keycloak releases on a monthly schedule (roughly).
- Keycloak is committed to harden their distribution for real world use
(this includes the operating system it runs on):
https://www.keycloak.org/server/fips#:~:text=Keycloak%20supports%20to%20run%20in,FIPS%20was%20enabled%20during%20installation.
- marketshare numbers
(https://6sense.com/tech/identity-and-access-management/keycloak-market-share)
indicate that Keycloak is up right there with AWS Cognito (around 2%)...
I'd say not too bad for an open-source project
- major companies run their production systems with Keycloak
(https://github.com/keycloak/keycloak/blob/main/ADOPTERS.md). One that
stands out in that list is Okta, a company that provides OAuth as a
managed service. Can't be too bad if they use Keycloak...
- there is no vendor lock-in when we choose Keycloak, we can replace it
with any other solution... that is compatible with our Apache License
- we would not include Keycloak in our release distributions, just the
configuration; maybe we'll have a Docker Compose file to help startup
Fineract together with Keycloak to get users started easily
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.)
The first part (authentication) is actually very easy. There is
excellent support for Spring Boot and auto-configuration now so that
this part is configuration only (5 lines or so in
application.properties); authorization involves some refactoring, but
I'd argue that that part needs some polishing anyway and we could take
this opportunity to clean things up a bit. Of course, every change has
risks... but the current implementation is also not risk free. We just
don't know how big that risk is in absence of pen tests, security audits
etc. I wouldn't know how to make a smaller proof of concept... and I'm
not so sure if we would gain anything by doing that. Overall, I don't
even think that this will be a large code change; big impact as a
feature, yes, but we deliver(ed) other features that contained much more
code changes.
Question: would we hold up the next release until we get this proposed
project done ?
No, I would proceed as planned. We can deliver these security
improvements in a separate release independently.
Third, banking systems are often audited by regulators and various
compliance groups. It would behoove us to validate any new strategy
before implementing. #
Proves my point. Again:
https://www.keycloak.org/server/fips#:~:text=Keycloak%20supports%20to%20run%20in,FIPS%20was%20enabled%20during%20installation.
We don't have anything to offer in that area at the moment.
Again, thanks for surfacing.
James
Please continue to challenge. This is what I can come up with to try to
answer your questions... no claim that all is complete. Others please
comment and/or correct.
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
