[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713661#comment-17713661
]
Ed Cable commented on FINERACT-1908:
------------------------------------
Comments from Avik:
Greetings everyone,
Please find Manoj and my thoughts on this.
{quote}BCrypt Support Module for Keycloak{quote}Good insight.
{quote}Auth-z/ RBAC / OPA{quote}
This should be the top priority after auth-n.
JWT typically is not meant to go to IAM/Keycloak for verifying the token.
Should it go to IAM just for the auth-z part?
In FINCN, permissions were published to user attributes which in turn reflected
inside the JWT making it huge.
We ran into debate on the best way to handle / publish permissions while
fitting it into user / architectural contexts (ex:- keep permissions in the
module, publish from config to Keycloak, identity/separate SDK, sidecars / fit
into k8s lifecycle events, reference OPA based implementation, bundle with
provisioner events, is Postman collection starting point acceptable for MVP,
etc. These approach points mentioned are not mutually exclusive and can be
complementary or non-complementary to each other)
{quote}Auth-n{quote}
A single auth-n mode should suffice. OIDC with JWT will nicely interoperate
with FINCN and PHEE architectures but JWT isn't a must if a better design can
be achieved.
The first two main milestones I would like to vote for is auth-n external
security module MVP and auth-z external security module MVP.
{quote}keep backwards compatibility for a couple of major releases{quote}
Should have (2nd phase or after RBAC) vote.
Suggestion to then move the old Fineract IAM code to a separate repo or remove
it from fineract to reduce Fineract technical debt?
{quote}automated tools for migration{quote}
{quote}we can migrate existing user accounts out of Fineract’s database tables
{quote}Nice to have vote.
{quote}but the tool that will be used as a third party security provider should
cover the use cases previously listed.{quote}
Food for thought on which other Keycloak (or IAM) modules can support the
security certification features mentioned by Victor without a lot of custom
code generating technical debt for Fineract. Regarding the 14 additional
points, I agree that they are must have for certifications but if we are
evaluating those considerations now, the evaluation process might take much
longer to look into Cognito, Okta, etc.
Possibly omitted items thoughts :-
* Account level permissions of who can read and write to an account (Fineract
has some loan officer related permissions and group / center related
permissions which ideally shouldn't be part of external auth-z MVP).
* Office and other entity related data visibility should be evaluated for
descoping from implementation and design or scoped for inclusion at a later
stage.
* Size of OIDC/JWT token / latency during login if it's part of the design -
some documentation on the tradeoffs thought process that went in.
> 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)
