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
