Re: Improved security...

[James Dailey <ja...@gmail.com>]

Ping.  Let's bring this discussion to a close.

I'm hearing support for moving away from "roll your own"(as in cigarettes
and software dev), but that should not mean a loss of flexibility for those
who have already addressed this issue in their production environments.
i.e. I don't think we have a 100% agreement to use KeyCloak but rather
KeyCloak should be possible, and could be one of several options.

The proposal is to continue to use the Spring Security (Resource Server )
and make different auth-servers possible.

That said, we may still have some open questions around how role
definitions (and fine grained permissions) are part of the business logic
or business requirements.  So, we should be somewhat careful there to make
it clear what we are doing and how that will change the experience.  I am
thinking in particular how the MifosUI is utilizing the schemes in fineract
for some functionality that supports workflows.

@Aleksandar Vidakovic  - can you comment on this?

On the topic of constraining choices like BasicAuth - It is not in the
nature of this project to make things more difficult, however, we should
make it clear to people using this system in production where the security
practices should be enforced.  One way is to make it clear in the logs that
basicAuth is not appropriate for production.  We've tried to be clear about
this but I wonder if it really is sinking in.

I'd also like to ask for a clear set of documentation on Resource Server vs
Authorization Server and the design we're deciding upon.

I found this on Stack Overflow
https://stackoverflow.com/questions/16228193/oauth-2-separating-resource-server-and-authorization-server.

<https://stackoverflow.com/questions/16228193/oauth-2-separating-resource-server-and-authorization-server.>

OAauth2 framework docs : https://www.rfc-editor.org/rfc/rfc6749

(A) The client requests an access token by authenticating with the
> authorization server and presenting an authorization grant.
> (B) The authorization server authenticates the client and validates the
> authorization grant, and if valid, issues an access token and a refresh
> token.
> (C) The client makes a protected resource request to the resource server
> by presenting the access token.
> (D) The resource server validates the access token, and if valid, serves
> the request.
> (E) Steps (C) and (D) repeat until the access token expires. If the client
> knows the access token expired, it skips to step (G); otherwise, it makes
> another protected resource request.
> (F) Since the access token is invalid, the resource server returns an
> invalid token error.
> (G) The client requests a new access token by authenticating with the
> authorization server and presenting the refresh token. The client
> authentication requirements are based on the client type and on the
> authorization server policies.
> (H) The authorization server authenticates the client and validates the
> refresh token, and if valid, issues a new access token (and, optionally, a
> new refresh token).



James Dailey


James Dailey



On Mon, Apr 24, 2023 at 6:09 PM Petri Tuomola <pe...@gmail.com>
wrote:

> 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 <ja...@gmail.com> wrote:
>
> Thanks Petri -
>
> On Fri, Apr 21, 2023 at 6:24 PM Petri Tuomola <pe...@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 <ja...@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 <
>> ngangawillie84@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 <
>>> muhammad@elshafie.me> wrote:
>>>
>>>> +1 for keycloack
>>>>
>>>> On Fri, Apr 21, 2023, 11:47 PM Aleksandar Vidakovic <
>>>> cheetah@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
>>
>>
>

Re: Improved security...

[James Dailey <ja...@gmail.com>]

See also the discussion here on auth

https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713661#comment-17713661



On Tue, Jun 6, 2023 at 7:54 PM Aleksandar Vidakovic <
cheetah@monkeysintown.com> wrote:

> On 07/06/2023 01:58, James Dailey wrote:
>
> Ping.  Let's bring this discussion to a close.
>
> +1
>
>
> I'm hearing support for moving away from "roll your own"(as in cigarettes
> and software dev), but that should not mean a loss of flexibility for those
> who have already addressed this issue in their production environments.
> i.e. I don't think we have a 100% agreement to use KeyCloak but rather
> KeyCloak should be possible, and could be one of several options.
>
> In fact, we don't even need to decide if Keycloak will become our default
> OAuth solution... we can provide configuration examples for any other OAuth
> server... just saying that Keycloak is probably the easiest to set up in a
> demo/local test. Note: the Apache infrastructure people seem to experiment
> with Keycloak as a single sign on solution.
>
>
> The proposal is to continue to use the Spring Security (Resource Server )
> and make different auth-servers possible.
>
> +1
>
>
> That said, we may still have some open questions around how role
> definitions (and fine grained permissions) are part of the business logic
> or business requirements.  So, we should be somewhat careful there to make
> it clear what we are doing and how that will change the experience.  I am
> thinking in particular how the MifosUI is utilizing the schemes in fineract
> for some functionality that supports workflows.
>
> @Aleksandar Vidakovic  - can you comment on this?
>
> The goals here are:
>
> - to leave no (or at least as few as possible) traces of all those direct
> security checks in the business logic
>
> - i. e. the current authorization logic should reside in a separate module
> (that could be later replaced with alternatives... discussion for another
> day)
>
> - make sure that refactored code works with exactly the same tables and
> enforces the permissions exactly the same way we do now (included the way
> we allow currently password changes)
>
> - no REST API changes (aka no changes to Mifos UI, 100% backwards
> compatible)
>
>
> On the topic of constraining choices like BasicAuth - It is not in the
> nature of this project to make things more difficult, however, we should
> make it clear to people using this system in production where the security
> practices should be enforced.  One way is to make it clear in the logs that
> basicAuth is not appropriate for production.  We've tried to be clear about
> this but I wonder if it really is sinking in.
>
> Alright, then let's keep it (basic auth). We can plaster the log output
> with warnings on startup of Fineract (I think Petri suggested that)...
> update the documentation about the recommendation to use OAuth in
> production... and continue to tell everyone on the mailing list.
>
>
> I'd also like to ask for a clear set of documentation on Resource Server
> vs Authorization Server and the design we're deciding upon.
>
> I found this on Stack Overflow
> https://stackoverflow.com/questions/16228193/oauth-2-separating-resource-server-and-authorization-server.
>
> <https://stackoverflow.com/questions/16228193/oauth-2-separating-resource-server-and-authorization-server.>
>
> OAauth2 framework docs : https://www.rfc-editor.org/rfc/rfc6749
>
> (A) The client requests an access token by authenticating with the
>> authorization server and presenting an authorization grant.
>> (B) The authorization server authenticates the client and validates the
>> authorization grant, and if valid, issues an access token and a refresh
>> token.
>> (C) The client makes a protected resource request to the resource server
>> by presenting the access token.
>> (D) The resource server validates the access token, and if valid, serves
>> the request.
>> (E) Steps (C) and (D) repeat until the access token expires. If the
>> client knows the access token expired, it skips to step (G); otherwise, it
>> makes another protected resource request.
>> (F) Since the access token is invalid, the resource server returns an
>> invalid token error.
>> (G) The client requests a new access token by authenticating with the
>> authorization server and presenting the refresh token. The client
>> authentication requirements are based on the client type and on the
>> authorization server policies.
>> (H) The authorization server authenticates the client and validates the
>> refresh token, and if valid, issues a new access token (and, optionally, a
>> new refresh token).
>
>
>
> James Dailey
>
>
> --
Sent from Gmail Mobile