[jira] [Commented] (FINERACT-1908) Modular Security Architecture

["Victor Romero (Jira)" <ji...@apache.org>]

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

Victor Romero commented on FINERACT-1908:
-----------------------------------------

Hello Aleks,

 

I think that the proposal should include the functional needs for this change in the Security module:

 
 # Avoid concurrent sessions (staff users and end customers)
 # IP address whitelist
 # Device tracking (if a new device used for login is detected then a 2FA could be requested)
 # Geolocation of the session
 # Session expire policies, session refresh, session revoke.
 # Activity records of all the task executed by the users (staff and customers) done during the session
 # Password policies (not to repeat a password previously used, lenght, complexity, special characters).
 # TOTP, OTP, biometric device support
 # Password recovery (using challenges, secret question, 2FA)
 # Password block policies (failed attemps, unkown device, ip non whitelisted)
 # Password life cycle (request for change after X number of days, safe storage/deletion of previous used passwords).
 # PIN support (number as a PIN is supported for shortcut in non financial actions, like generating account statement (the account statement generation is another point because it is a .zip or pdf password protected).
 # HSM support. PIN, passwords, card numbers must use a HSM per regulation in Mexico.
 # For the project that we have executed we have extended some functionality to use X.509 (certificate/private key) in order to login, approve task, timestamp proof and sign documents (digital signature is legal in Mexico but if it is issued by the Federal Authorities).

I have this functional features in my mind because we had to implement them in order to certify the solution and offer the electronic channels like Web Banking, Mobile Banking, Remote Enrollment, Branches.

I agree that if we continue to use the Spring Security it is very limited, but the tool that will be used as a third party security provider should cover the use cases previously listed.

Also the migration of the passwords, grants, roles must be very clear, also we have to avoid any lock vendor around the security. 

 

> 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.9.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)