Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OPAAutoConfiguration to define common beans #22

Open
ali-jalaal opened this issue Jan 26, 2025 · 1 comment
Open

Add OPAAutoConfiguration to define common beans #22

ali-jalaal opened this issue Jan 26, 2025 · 1 comment

Comments

@ali-jalaal
Copy link
Contributor

ali-jalaal commented Jan 26, 2025

Expected behaviour

Define common beans as part of an auto-configuration to reduce manual configurations on clients side.

Actual behaviour

Clients should define objects/beans in their code to use the library, such as OPAClient and OPAAuthorizationManager.
It would be nice to have a more streamlined experience by defining pre-configured beans in an @AutoConfiguration class
which will be created in client applications by adding that can be used by clients.

How to improve

Define OPAAutoConfiguration class that will create the required beans:

@AutoConfiguration
@EnableConfigurationProperties(OpaProperties.class)
public class OpaAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean(OPAClient.class)
    public OPAClient opaClient(OpaProperties opaProperties) {
        return new OPAClient(opaProperties.getUrl());
    }

    @Bean
    @ConditionalOnMissingBean(OPAAuthorizationManager.class)
    public OPAAuthorizationManager opaAuthorizationManager(OpaProperties opaProperties) {
        return new OPAAuthorizationManager(opaClient(opaProperties), opaProperties.getPath());
    }
}

Then, clients can use the library without defining OPAClient and OPAAuthorizationManager beans/objects:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http, OPAAuthorizationManager opaAuthorizationManager) throws Exception {
        http.authorizeHttpRequests(authorize -> authorize.anyRequest().access(opaAuthorizationManager));
        return http.build();
    }
}

Moreover, considering @ConditionalOnMissingBean annotations, clients can define their own OPAClient and OPAAuthorizationManager beans. Fewer clients would be affected by changing the library's internal structure (e.g. constructors). Furthermore, OPAProperties can be used to reference externalized properties (depends on #21).

@chendrix
Copy link
Collaborator

This looks good to me. Seems like there's very little risk, and it maintains backwards compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants