Hi Adam and Aleksander - Please excuse the anticipation, but I heard you might have some good progress on the design thinking related this thread & FSIP MODULAR SECURITY ARCHITECTURE https://cwiki.apache.org/confluence/display/FINERACT/FSIP-1%3A++Modular+Security+Architectur e
I realize this may be a big project, and I make note of the 8 Sub-tickets that were part of the ticket https://issues.apache.org/jira/browse/FINERACT-1908 Should we keep these same tactical tickets and can we get some idea on who can work on the first few of them? The discussion on the Jira ticket is good - and provides a thread for anyone interested in following this. Thanks, James On Wed, Jun 7, 2023 at 4:55 AM James Dailey <jamespdai...@gmail.com> wrote: > 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 < > chee...@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 >
