[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1908:
-------------------------------------------
Fix Version/s: 1.10.0
(was: 1.9.0)
> Modular Security Architecture
> -----------------------------
>
> Key: FINERACT-1908
> URL: https://issues.apache.org/jira/browse/FINERACT-1908
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Aleksandar Vidakovic
> Assignee: Aleksandar Vidakovic
> Priority: Major
> Labels: FIPS
> Fix For: 1.10.0
>
> Attachments: FIPS-0001.pdf, image (9).png
>
>
> Background and Motivation
>
> Our current security architecture is based on a example in Spring Security’s
> documentation and implemented on top of JDBC. For a long time we’ve only
> supported basic authentication which was later complemented with a homegrown
> OAuth implementation and another module for one time passwords. On the
> authorization side we support a straight forward RBAC (role based access
> control) model again implemented on top of JDBC. This approach worked for
> quite a while, but end users and integrators wish a more flexible solution.
> Effectively, we are forcing users to adapt to our current security model. In
> most cases they have already existing security infrastructure (e.g.
> ActiveDirectory/LDAP for user info storage and role assignments) and would
> like to integrate Fineract with it. And last, in some more advanced and more
> complex setups the role/permission based access concept might not be
> sufficient for authorization; sometimes additional information (external to
> Fineract) might be needed for additional evaluation. The current setup makes
> it at the least very hard (if not impossible) to achieve these goals.
>
> h2. Target Personas
>
> * integrators
> * end users
> * BaaS
>
> h2. Goals
>
> * separate the current security infrastructure as much as possible from
> Fineract’s core; i. e. make it a custom module
> * create the OAuth Client aka Keycloak module as a drop-in replacement for
> the current security mechanics
> * delegate everything authentication/authorization related to 3rd party
> libs/frameworks/products/services
> * re-use 3rd party libs/frameworks/products/services user interfaces and
> remove corresponding views (e. g. user management) from Fineract web app
> * as minimal refactoring as possible in the short/mid term
> * keep backwards compatibility for a couple of major releases
> * provide good documentation and/or automated tools for migration
>
> h2. Non-Goals
>
> * Fineract as a standalone identity server
>
> h2. Proposed API Changes
>
> h3. AppUser
>
> Unfortunately this class is both JPA entity class and implements Spring
> Security’s "User" interface. The current dependencies and usage in code is
> not ideal (at least when it’s business logic), but the main challenge is that
> the database table behind this JPA entity is related pretty much all over the
> place via joins.
>
> h3. PlatformUserDetailsService
>
> Ideally this service should not be used directly anymore in Fineract’s core.
>
> h3. OAuth Client Auto Configuration
>
> After years of having multiple competing OAuth packages Spring consolidated
> their efforts in two libraries:
>
> {color:#000000}implementation
> "org.springframework.boot:spring-boot-starter-oauth2-client"{color}
> {{implementation
> "org.springframework.boot:spring-boot-starter-oauth2-resource-server"}}
>
> Especially the Keycloak configuration is very easy (3 lines in
> application.properties).
>
> h3. BCrypt Support Module for Keycloak
>
> Unfortunately Keycloak doesn’t support BCrypt hashing for passwords out of
> the box, but BCrypt is widely used in Spring Boot applications and the
> default for Fineract. It’s very easy to create an extension module for
> Keycloak to supprot BCrypt too; that way we can migrate existing user
> accounts out of Fineract’s database tables without forcing everyone to reset
> their passwords. Not a strict technical requirement, but helps to smooth the
> transition.
>
> h3. Open Policy Agent integration
>
> To my knowledge there is no official Spring Security module/support for Open
> Policy Agent. Doesn’t really matter that much, because the communication with
> the OPA server is pretty much handled via one endpoint (again, for Java there
> is no official client, but the implementation is easy). Enforcing the OPA
> rules happens then with a Spring Security Voter. Some more thought needs to
> go into what information we send to OPA. At the least we would need:
> * user name
> * authorities/roles
> * service name and function name that is being executed
> * optional: parameters that are passed to the function
> It should be possible to intercept these calls with minimal coding effort via
> annotations and aspect oriented programming.
>
> h2. Risks
>
> TBD
>
> h2. ETA
>
> TBD
> h2. Diagrams
> !image (9).png|width=975,height=1168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
