Provide a fluent API to set up Quarkus Security

[sberyozkin]

Description

Hantsy Bai has linked to the following Spring Security example:

@Configuration
public class SecurityConfig {

    @Bean
    SecurityFilterChain springWebFilterChain(HttpSecurity http) throws Exception {
        return http
                .httpBasic(AbstractHttpConfigurer::disable)
                .csrf(AbstractHttpConfigurer::disable)
                .sessionManagement(c -> c.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .authorizeRequests(c -> c
                        .antMatchers("/", "/info").permitAll()
                        .antMatchers(HttpMethod.GET, "/posts/**").permitAll()//.hasAuthority("SCOPE_read:posts")
                        .antMatchers(HttpMethod.POST, "/posts/**").hasAuthority("SCOPE_write:posts")
                        .antMatchers(HttpMethod.PUT, "/posts/**").hasAuthority("SCOPE_write:posts")
                        .antMatchers(HttpMethod.DELETE, "/posts/**").hasAuthority("SCOPE_delete:posts")
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt)
                .cors().and().build();
    }

While we can do it with combining HttpAuthenticationMechanism/IdentityProvider and configuration, supporting something similar to the above in Quarkus can be of interest

Also CC @stuartwdouglas

[hantsy]

Found in the old PicketLink docucmentation, https://docs.jboss.org/picketlink/2/latest/reference/html-single/, there are some work like this.

public class HttpSecurityConfiguration {
​
​    public void configureHttpSecurity(@Observes SecurityConfigurationEvent event) {
​        SecurityConfigurationBuilder builder = event.getBuilder();
​
​        builder
​            .http()
​                .forPath("/*.jsf")
​                    .authenticateWith()
​                        .form()
​                            .loginPage("/login.jsf")
​                            .errorPage("/loginFailed.jsf")
​                .forPath("/admin/*")
​                    .authorizeWith()
​                        .role("Administrator");
​    }
​}

[sberyozkin]

@michalvavrik This one would have a very good impact, so among all the issues you may want to choose from, that would be most interesting IMHO.
It should be done in phases IMHO, first we do it nice and easy to set anything related to the built-in authentication: basic, form, mtls, proactive/on/off, path-based HTTP policies, etc. It is a large enough phase though.
Then I reckon we should add oidc, jwt, ets specific builders - which can be used individually or as part of this common builder API via typed options, instead of form(), something like auth(Auth.OIDC) which would be recognized if quarkus-oidc is on the class path, etc...
But yes, it can be a fairly time consuming/long term issue, but it can be done in parts for sure...

[michalvavrik]

Sure, thank you for suggestion and nice description.

[geoand]

Is this still relevant?

[hantsy]

Is there a programmatic config instead of the annotations?

[michalvavrik]

Is this still relevant?

More importantly, it is next to impossible. It either requires:

• to move a lot of stuff to runtime (and I mean a lot!),
• or to basically provide users with some kind of builder that will be implementation of SmallRye Config source at build time
• or some other trick with config as config interceptor that will do pretty much some as config source

Is there a programmatic config instead of the annotations?

Yeah, but it really doesn't go down with intention to do as much as possible at build time. The reason why I didn't move on this is that any implementation will not provide you will level of programmatic config that Spring and other FWs because you won't be able to inject stuff and only with difficulty access existing config properties (you need to avoid circular reference).

Anyway, this is on my list.

[hantsy]

For security annotations, the reason I dislike it is it will affect my APIs testing when applying them on Rest API methods.

In Spring, I can ignore the security config when focusing on API development and testing.

And Quarkus security annotation is not flexible for applying a fine-grained security rule on URIs, in some of my past projects, simple role/group/permission can not satisfy the security requirements.

In spring security it is easy to control security on a URI path via custom codes to decide if it is authorized.

.antMatchers(HttpMethod.DELETE, "/posts/**").access(AuthencationContext, xxx -> a callback)

[hantsy]

Or provides an article to describe how to apply the fine-grained security control using the existing features provided in Quarkus 3.x.

[hantsy]

Check the current security docs, the security control is still based on annotations, and provide limited extension points.

[michalvavrik]

I hear you @hantsy. I have other issues with higher priority on my list, therefore I removed myself from this issue until they are done. Maybe someone else will pick it up. Thanks.

[michalvavrik]

I believe now that most of the quarkus.http.auth is runtime configuration, we certainly can implement all examples given here in the comments / issue description. I won't look in the next 2 months, but I wanted to let you all know that situation has changed there is reasonable way to do this. I'm also happy to give a hand to anyone who will give this issue try.