Quarkus Oauth2 quarkus.oauth2.enabled doesn't seem to work

[manodupont]

Describe the bug
Setting this quarkus.oauth2.enabled=false doesnt "disable" the oauth2 features. I need to comment out my annotations about "@RolesAllowed" to disable oauth verification.

Expected behavior
Setting this quarkus.oauth2.enabled=false only, would make all security "checks" disabled so i don't need to comment out any other code lines.

Actual behavior
Setting this quarkus.oauth2.enabled=false doesnt "disable" the oauth2 features. I need to comment out my annotations about "@RolesAllowed" to disable oauth verification.

To Reproduce
Steps to reproduce the behavior:

1. Set this property: quarkus.oauth2.enabled=false
2. Add a @RolesAllowed("anything") on a route.
3. Request this route.
4. You will get a 403.

Environment (please complete the following information):

• Output of uname -a or ver:
• Output of java -version: 11
• GraalVM version (if different from Java): --
• Quarkus version or git rev: 1.5.2.FINAL
• Build tool (ie. output of mvnw --version or gradlew --version): 3.6.3

[ejba]

Hi, can I try to fix this?

[geoand]

@manodupont quarkus.oauth2.enabled is a build time property. That means that if you built the application with quarkus.oauth2.enabled=true (or left it out as true is the default), the setting quarkus.oauth2.enabled=false at runtime will have no effect.

Are you sure you are using it properly?

[geoand]

Hi, can I try to fix this?

Le's see first if this is just a misuse issue

[sberyozkin]

If the method is role protected then the RBAC layer just wants to enforce it, it does not know how Principal was created

[ejba]

@sberyozkin I understand your point. However, it's confusing at first sight to learn what's the expected behavior when disabling the oauth2 extension and have multiple methods as role protected.

At least, it should be documentation that explains in detail how Quarkus behaves in this case.
What do you think?

[manodupont]

Ok. But im more confused after all that :)

So what is setting it to false actually doing ?

Sorry for my misunderstanding!

[ejba]

I assume that disables oauth2 support only, not whole RBAC layer from protecting all methods.
You can have multiple authentication mechanism support activated, but you are just disabling one (oauth2). It seems to me the rationale behind it.

[manodupont]

Oh right. I Didn’t test that... it might be right.

Ok well i guess its a no bug then. Thanks!

[geoand]

Feel free to close the issue if you believe it's resolved

…

On Thu, Jul 2, 2020, 21:06 Manuel Dupont ***@***.***> wrote: Oh right. I Didn’t test that... it might be right. Ok well i guess its a no bug then. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10427 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBMDP3YPTLBLRHJWGX6RGTRZTEBVANCNFSM4OOY4YZA> .

[sberyozkin]

@ejba

However, it's confusing at first sight to learn what's the expected behavior when disabling the oauth2 extension and have multiple methods as role protected.

Right this or any other extension dealing with the authentication is only populating a Securityidentity. RBAC level is in the next phase.
If one disables oauth2/etc then all what is being achieved is that no auth mechanism is available which can do something meaningful with Bearer sometoken.

I wonder though if the time has come to introduce a property like a default role (someone has suggested it already). Or have a property like disable-role-based-access-control... Or how about proactive-authorization=false which will be disable RBAC if SecurityIdentity is not available...
CC @stuartwdouglas Hi Stuart, what do you think ?

[loicmathieu]

Late to the party but yes, quarkus.oauth2.enabled=false only disable the OAuth2 security provider not Quarkus Security in it's entirety.

This is a build time property as the classical use case is to use an embedded security provider in dev/test and the OAuth2 in production. As dev/test re-play build steps you it works.

I don't think there is currently a way to disabled Quarkus security fully, at least it's not documented inside the Security Guide (https://quarkus.io/guides/security). If it's a legitimate use case (but it can also create a security threat to enable bypassing the security layer) maybe we should add it.

When we design the OAuth2 extension we don't offer a way to disable the security layer because we think people will use an embedded provider in dev/test (via the quarkus-elytron-security-properties-file for example) and the Oauth2 security otherwise.

[stuartwdouglas]

I have implemented something here: #10487

[sberyozkin]

Hi @stuartwdouglas That looks good, but I'm not sure it is related to this one, here the user would like to disable some authentication module and the authorization check at runtime

[stuartwdouglas]

I thought the use case here was to disable security in testing?

[sberyozkin]

@manodupont, Hi, can you confirm please ?

[manodupont]

No i meant at runtime too. I thought it was a single flag to turn every security and roles checking “off”.

[stuartwdouglas]

So you can do it at runtime as well, but it requires some custom code:

@Alternative
@Priority(Interceptor.Priority.LIBRARY_AFTER)
@ApplicationScoped
public class DisabledAuthController extends AuthorizationController {

    @Override
    public boolean isAuthorizationEnabled() {
        return false;
    }
}

Including this bean in your application will disable security. If you want to make it configurable just make it inject a configuration property using MP config.

I am a bit hesitant about including this as a general config option, it just feels a bit dangerous.

[manodupont]

ok. thanks everybody.

[ejba]

It would be great to have this documented somewhere.
What do you think?

[sberyozkin]

I'd say so, I believe we've had a good number of similar queries, not sure where, may be at https://quarkus.io/guides/security to start with, have a section How to Disable Authorization. I think it should show the injection of the custom property like authorization-enabled to highlight the point Stuart made, @ejba Hi, are you Ok with doing another PR :-) ?

[ejba]

Of course! :)

[sberyozkin]

@ejba Hi, I was planning to add this example to the open PR (to do with repurposing security.adoc) but I'm not sure
what is AuthorizationController, @stuartwdouglas, can you clarify please ? I can't see it Quarkus workspace...

[ejba]

Is this one? import io.quarkus.security.spi.runtime.AuthorizationController;

[stuartwdouglas]

quarkus/extensions/security/runtime-spi/src/main/java/io/quarkus/security/spi/runtime/AuthorizationController.java

Line 9 in fa6cede

public class AuthorizationController {

[sberyozkin]

@ejba @stuartwdouglas thanks :-), not sure why I'm not seeing it, may be because I have Eclipse workspace bugs. OK, So I'll push the update the proposed security-customization.adoc

[abhinavg18]

So you can do it at runtime as well, but it requires some custom code:

@Alternative
@Priority(Interceptor.Priority.LIBRARY_AFTER)
@ApplicationScoped
public class DisabledAuthController extends AuthorizationController {

    @Override
    public boolean isAuthorizationEnabled() {
        return false;
    }
}

Including this bean in your application will disable security. If you want to make it configurable just make it inject a configuration property using MP config.

I am a bit hesitant about including this as a general config option, it just feels a bit dangerous.

After doing this, I receive the below error. [error]: Build step io.quarkus.arc.deployment.ArcProcessor#validate threw an exception: javax.enterprise.inject.spi.DeploymentException: Found 3 deployment problems: [1] Ambiguous dependencies for type io.quarkus.security.spi.runtime.AuthorizationController and qualifiers [@Default] - java member: io.quarkus.vertx.http.runtime.security.HttpAuthorizer#controller - declared on CLASS bean [types=[io.quarkus.vertx.http.runtime.security.HttpAuthorizer, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.vertx.http.runtime.security.HttpAuthorizer] - available beans: - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, org.acme.security.keycloak.authorization.DisabledAuthController, java.lang.Object], qualifiers=[@Default, @Any], target=org.acme.security.keycloak.authorization.DisabledAuthController] - CLASS bean [types=[io.quarkus.test.security.TestAuthController, io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.test.security.TestAuthController] - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.security.spi.runtime.AuthorizationController] [2] Ambiguous dependencies for type io.quarkus.security.spi.runtime.AuthorizationController and qualifiers [@Default] - java member: io.quarkus.security.runtime.interceptor.RolesAllowedInterceptor#controller - declared on INTERCEPTOR bean [bindings=[@RolesAllowed(value = [""])], target=Optional[io.quarkus.security.runtime.interceptor.RolesAllowedInterceptor]] - available beans: - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, org.acme.security.keycloak.authorization.DisabledAuthController, java.lang.Object], qualifiers=[@Default, @Any], target=org.acme.security.keycloak.authorization.DisabledAuthController] - CLASS bean [types=[io.quarkus.test.security.TestAuthController, io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.test.security.TestAuthController] - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.security.spi.runtime.AuthorizationController] [3] Ambiguous dependencies for type io.quarkus.security.spi.runtime.AuthorizationController and qualifiers [@Default] - java member: io.quarkus.security.runtime.interceptor.AuthenticatedInterceptor#controller - declared on INTERCEPTOR bean [bindings=[@Authenticated], target=Optional[io.quarkus.security.runtime.interceptor.AuthenticatedInterceptor]] - available beans: - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, org.acme.security.keycloak.authorization.DisabledAuthController, java.lang.Object], qualifiers=[@Default, @Any], target=org.acme.security.keycloak.authorization.DisabledAuthController] - CLASS bean [types=[io.quarkus.test.security.TestAuthController, io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.test.security.TestAuthController] - CLASS bean [types=[io.quarkus.security.spi.runtime.AuthorizationController, java.lang.Object], qualifiers=[@Default, @Any], target=io.quarkus.security.spi.runtime.AuthorizationController]

The only change I did was to annotate a test with @testsecurity(authorizationEnabled = false) and created a DisabledAuthContoller. When I do mvn clean compile install, I receive the above error that I am inject a bean which is ambiguous
@stuartwdouglas