Enable authentication by default if a SecurityIdentity-providing module is enabled

[sberyozkin]

Description
Lets consider a case where only the authenticated users can access a given endpoint. At the moment, one has to enable the SecurityIdentity-providing module, example, quarkus-oidc and express a requirement that the authentication is required (in application.properties, see below, or with @Authenticated):

# Step1: OIDC user authentication is enabled by default:
quarkus.oidc.enabled=true
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app

# Step2: Request that only the authenticated users can go through
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

This is a process familiar to a good number of developers. However I propose that we take an opinionated approach (it is Quarkus, right :-) ? ) and say that: if you are planning to properly protect your application, you don't have to do 2 steps only 1 step, and if you are still interested in the semi-secured approach then well, please do Step 2 and tell Quarkus which paths are not secure.

See, we have a lot of flexibility in allowing the anonymous requests in, but ultimately, it is not a good pattern for any application where the security matters. Any anonymous request is a DOS threat. And in general we should encourage the users to take it seriously, as opposed to making it super easy to enter the endpoint URL space, with exactly the opposite to what is proposed: if you are planning to properly protect your application, you have to do 2 steps , and if you are still interested in the semi-secured approach then yeah, don't worry about Step 2 :-)

It may be different from what Spring Security or other frameworks do OOB, but may be it is not a bad thing :-)

This is why IMHO we should try it out for 1.1.0 and make it easier for the users who want to make sure the security is tight OOB. Lets give it a go and collect the feedback and see what we get. I can expect some people say, oh, now my /health method can not be invoked, we say - sure, just add a 'permit' policy for it, but then some users may notice their configuration can actually become simpler. We doc this is a trial and will revert if the majority of the users will simply say no, we can't do it...

Implementation ideas
Not sure yet, but perhaps quarkus-oidc/etc can provide say SecurityIdentityEnabledBuildItem if it s enabled.

CC @stuartwdouglas @pedroigor and everyone else who is interested :-)

[evanshortiss]

Agree with @sberyozkin suggestion here in "Step 2". If someone annotates a resorce with "Authenticated" but does not have "quarkus-keycloak-authorization" in the pom.xml it should fail? See my example in #6596

[Erfankam]

I like to work on it. May I?

[stuartwdouglas]

We already have the option in resteasy to deny access to endpoints without security annotations, which IMHO is enough. Applying a blanket 'authenticated' by default is IMHO a bit confusing, as it means @permitAll annotations would not work (as the request would be rejected before it reaches the bean).

[Erfankam]

I like to work on it. May I?

?

[sberyozkin]

@stuartwdouglas Hi Stuart, the case which is of interest to some users is where they just don't want to add the annotations in order for the authentication to take place. Yes, if some users add @PermitAll then it will be confusing to them why it is not honoured - but there will be the documentation explaining the auth is required by default or we can fail the build if it is enabled and @PermitAll is available (or ask them to disable the proactive auth), etc.
The point I've tried to make in the description is that as it stands now, the users who need to secure their endpoints need to do more work compared to the users who only need the public access. It would be interesting to find out how many secured vs public endpoints are used in the production :-)
Yes - making the auth enabled by default would please some users and annoy others :-) but it may not be too bad for Quarkus to send a signal the security is enabled by default IMHO.

[danelowe]

Could the extensions have a build time transformer that adds @Authenticated annotation to endpoints if a configuration setting is enabled?

For my use case, I think the current configuration option (quarkus.http.auth.permission.authenticated.paths) works well and makes it clear which paths would be public.

I just thought I'd mention this as I've recently noticed that quarkus-hibernate-validation uses a similar strategy where it adds annotations to methods in order to enable an interceptor.

[stuartwdouglas]

If you are using JAX-RS you will be able to use quarkus.security.jaxrs.default-roles-allowed=** to make endpoints require auth by default in 2.2.0.Final.

[fleyer]

Hey there, sorry to bump this issue but I ve encounter a strange behavior. I ve set as the documentation shows the quarkus.http.auth."permission".policy to authenticated with the appropriate paths and I m using the oidc package. So here is the problem : when I pass a good token, the server returns 200, when I pass a bad token the server returns 401. But if I don t pass a token the server retruns 200.

This is with quarkus 2.9.2 I believe and my end point does not have any annotation ( role allowed authenticated ).

In this case I m expecting to receive a 401.
The documentation says that both annotation and quarkus policy should return a succes to grant access.

What if there is only one?
Thanks

[michalvavrik]

Hey there, sorry to bump this issue but I ve encounter a strange behavior. I ve set as the documentation shows the quarkus.http.auth."permission".policy to authenticated with the appropriate paths and I m using the oidc package. So here is the problem : when I pass a good token, the server returns 200, when I pass a bad token the server returns 401. But if I don t pass a token the server retruns 200.

@fleyer that's way to little information, at the very least, I'd require all your config options. Please open dedicated issue with reproducer. Thank you