@TestSecurity with @PermissionsAllowed annotated endpoint

[ralph089]

I've been trying to use the @TestSecurity and @PermissionsAllowed annotations in my Quarkus application, but I'm facing some issues.

An endpoint has been annotated with @PermissionsAllowed:

@Path("/my-endpoint")
public class MyEndpointResource {

    @GET
    @PermissionsAllowed("endpoint:read")
    public Response getMyData() {
        return Response.ok("My data").build();
    }
}

When using @TestSecurity in my test class I can only specify roles. I tried it using @OidcSecurity and specifiying the scopes claim, but this also has no effect. The tests are failing due to unauthorized access.

I've got a use case, where I fetch the permissions of a user using a SecurityIdentityAugmentor and a DB call (this SecurityIdentityAugmentor is not being used when using @TestSecurity). Creating all the possible combinations through a quarkus.http.auth.policy upfront and relate the permission combinations to "test roles" that I use in my tests would probably be possible, but a lot of overhead.

Is there any other way on how to specify the permissions for a test case for a given user?

[sberyozkin]

@ralph089, Hi, can you please show how did you use @OidcSecurity ? Though to really fix it we should add a new permissions attribute, @michalvavrik, Michal, do you agree ?

[michalvavrik]

I tried it using @OidcSecurity and specifiying the scopes claim, but this also has no effect. The tests are failing due to unauthorized access.

I think this is expected (from implementation POV, not user POV) because we augment identity and not the token from which it would be mapped. It would be great to have simple reproducer as it makes fixes easier and guarantees your use case is what we are fixing.

this SecurityIdentityAugmentor is not being used when using @testsecurity

I remember there is a switch when we serve identity directly and we could always force authentication instead. It would be great to have simple reproducer as it makes fixes easier and guarantees your use case is what we are fixing.

Though to really fix it we should add a new permissions attribute, @michalvavrik, Michal, do you agree ?

Well, yeah. There is also option that we fix (not broken per say) mapping between claims and permissions, but new permissions attribute sounds good to me.