feat: implement custom resolvers for custom auth over oauth2

[Aiosa]

Resolves #11052

Describe changes proposed in this pull request:

• SecurityMapper no longer retrieves study groups, these have their own mapper
• SecurityRepository now is parametrized by another generic object, that is given by the auth configuration to the repository if used. Such repository then decides whether it is able to be used in the current context. Newly, repository can be switched between with security.repository.type:
  • cbioportal: the default, injects SecurityMyBatisRepository
  • disabled: allows all access, injects FullAccessResolver
  • [any other]: custom implementation + custom args

There is included a LsaaiOauth2DrivenResolver that demonstrates the usage; I would like to remove this implementation as it is specially designed to work for my usecase. It can be used like this:

security.repository.type=lsaai
security.repository.lsaai.userinfo=https://example.com/oidc/userinfo

I would like a discussion on whether this is a good design, or whether there are some issues (interaction with different flows, usage in different scenarios, over-complexity due the need to compile / build images yourself...). But IMHO this is a crucial feature if this app should be used in production systems - being able to customize authentication and authorization to your needs.

No new tests are necessary since this PR just modularizes the current behavior, so the current test suite should be sufficient.

Background Info

• LS AAI

Checks

• The commit log is comprehensible. It follows 7 rules of great commit messages. We can fix this during merge by using a squash+merge if necessary
• Has tests or has a separate issue that describes the types of test that should be created. If no test is included it should explicitly be mentioned in the PR why there is no test.
• Is this PR adding logic based on one or more clinical attributes? If yes, please make sure validation for this attribute is also present in the data validation / data loading layers (in backend repo) and documented in File-Formats Clinical data section!
• Make sure your PR has one of the labels defined in https://github.com/cBioPortal/cbioportal/blob/master/.github/release-drafter.yml (GUI does not let me add them)

[inodb]

Thanks @Aiosa ! Let's discuss if an alternative is to use keycloak as a middleman instead and manage custom resolvers there: https://www.keycloak.org/docs/latest/server_development/index.html#_providers

[Aiosa]

That indeed is a possible solution (at least not really looking into details). Of course cbioportal cannot support all the authentication designs out there, but so cannot keycloak.

There is included a LsaaiOauth2DrivenResolver that demonstrates the usage; I would like to remove this implementation as it is specially designed to work for my usecase.

The idea is that cbioportal implements the same logics as before, but in a way that someone can add custom resolver and compile own image. The same logics as keycloak supports I believe.

I would like to avoid dealing with keycloak, since it makes things harder to manage - unclear sources of auth errors, at least two more containers to run, unclear design (confusing for newcomers), bad user experience (some apps use lsaai, some keycloak, I cannot change every service we run just because of cbioportal), ...

[Aiosa]

I have tested this implementation with a private study, mapping OIDC provider user groups to the study user groups, and it works.
I am willing to write a documentation for it. Shall I remove the custom implementation and get it ready? What is else needed?

[Aiosa]

@inodb I could also add some 'generic OIDC' resolver implementation configurable enough so that people can use it without compilation requirements.... would that be desirable? That would not be really a 'custom resolver'. If no, I would remove the LSAAI implementation from this PR and make it ready for further steps?

[Aiosa]

I added docs, removed the irrelevant implementation of my own security repository, and also added ability to configure oidc with acr_values query. This, together with the repository, can implement the MFA authentication as well - you provide in properties file custom acr string, and later verify in a custom security repository, that the token contains what you expect.

The only thing I did not manage was to add ability to provide a MAP as a param to be more general, now it is implemented only for acr_values field.

Example of doing MFA with the current approach:

security.custom.oauth.request.acr=https://refeds.org/profile/mfa
security.repository.lsaai.requireMFA=https://refeds.org/profile/mfa

Later in custom repository:

@Service
@ConditionalOnProperty(name = "security.repository.type", havingValue = "lsaai")
//todo also condition that auth is oauth2
public class LsaaiOauth2DrivenResolver implements SecurityRepository<OidcUser> {

   ....

    var token = user.getIdToken();  //see  implements SecurityRepository<OidcUser>, we get is as argument
    // Check if acr=requireMFA if specified
    if (requireMFA != null) {
        String acr = token.getClaimAsString("acr");
        if (!requireMFA.equals(acr)) {
            log.warn("ACR invalid: user {} not authorized: required {}, found {}", username, requireMFA, acr);
            return false;
        }
    }