Update SecurityIdentity to list owned Permissions and allow simpler permission checks

[sberyozkin]

The main purpose of this PR is to make it possible to simplify the way @PermissionAllowed are enforced by default at the Quarkus level.

At the Quarkus level, when no (recently introduced) @PermissionChecker is used, the only way for users to have @PermissionAllowed checks enforced is basically do these checks themselves by registering a custom SecurityidentityAugmentor and adding a custom permission checker function:

For example (from the Quarkus docs):

@ApplicationScoped
public class PermissionsIdentityAugmentor implements SecurityIdentityAugmentor {

    @Override
    public Uni<SecurityIdentity> augment(SecurityIdentity identity, AuthenticationRequestContext context) {
    //...
        Permission possessedPermission = new MediaLibraryPermission("media-library",
                new String[] { "read", "write", "list"}); 
        return QuarkusSecurityIdentity.builder(identity)
                .addPermissionChecker(new Function<Permission, Uni<Boolean>>() { 
                    @Override
                    public Uni<Boolean> apply(Permission requiredPermission) {
                        boolean accessGranted = possessedPermission.implies(requiredPermission);
                        return Uni.createFrom().item(accessGranted);
                    }
                })
                .build();
       };
}

Where the users need to correctly write the permission checker function making sure it is permission which is meant to be associated with the identity is used to call implies , not the required one... And there is no way to check on SecurityIdentity which permissions it owns.

@FroMage and @michalvavrik worked out a plan to make it easier to implement such functions, but IMHO users should be totally shielded from having to write such checkers. We do not ask users to manually write role checks, and we should not ask them to do it for permissions. They can do if they really want to, but it should be avoidable.

The above code should look like this:

@ApplicationScoped
public class PermissionsIdentityAugmentor implements SecurityIdentityAugmentor {

    @Override
    public Uni<SecurityIdentity> augment(SecurityIdentity identity, AuthenticationRequestContext context) {
        return QuarkusSecurityIdentity.builder(identity)
                .addPermission(new MediaLibraryPermission("media-library", new String[] { "read", "write", "list"});)
                .build();
       };
}

And Quarkus Security will do the required checks itself, by checking SecurityIdentity#getPermissions() added in this PR.

See also quarkusio/quarkus#43717

[michalvavrik]

I kinda said it all in my comments in quarkusio/quarkus#43717. I can't think of anything else to comment here.

FWIW idea to add addPermission to the QuarkusSecurityIdentity.Builder is brilliant.

[FroMage]

Seems like a good idea.

[sberyozkin]

@michalvavrik Michal, I've totally missed Steph approved, what should we do here, I'm assuming you are OK with keeping a method allowing to list current permissions. I can drop the methods for checking them, it can be done later, but indeed, letting users list posessed permissions seems useful, similarly to what users can do with getRoles, are you OK with this plan ?

[michalvavrik]

@michalvavrik Michal, I've totally missed Steph approved, what should we do here, I'm assuming you are OK with keeping a method allowing to list current permissions. I can drop the methods for checking them, it can be done later, but indeed, letting users list posessed permissions seems useful, similarly to what users can do with getRoles, are you OK with this plan ?

Honestly, I am still worried that users will consider following interchangeable:

# 1
return identity.checkPermissionBlocking("edit");
# 2
for (Permission p : identity.getPermissions()) {
            if (p.implies(new StringPermission("edit")) { return true}
}
return false;

(it's metacode, don't take it literately please). Because that is what we ourselves do in Quarkus, we mostly (if not always) use getRoles and not io.quarkus.security.identity.SecurityIdentity#hasRole. I have already proposed here something like that here.

If you said in the getPermissions javadoc that it checking of permissions must be performed with the checkPermission then I think this PR makes positive changes and should be merged.

[sberyozkin]

Sorry Michal, I did not quite get your concern about the interchangeable code above, it does look interchangeable to me or did I miss something ?

[michalvavrik]

Sorry Michal, I did not quite get your concern about the interchangeable code above, it does look interchangeable to me or did I miss something ?

I don't know, it quite hard for me to explain it because I am not sure where we disagree. I can try again, I hope I am not repeating myself and it is useful:

# 1
return identity.checkPermissionBlocking("edit");
# 2
for (Permission p : identity.getPermissions()) {
            if (p.implies(new StringPermission("edit")) { return true}
}
return false;

is not interchangeable because you can do for example this:

• https://github.com/quarkusio/quarkus/blob/453add378a658aff7b69dc4cebd06f508e32773b/extensions/keycloak-authorization/runtime/src/main/java/io/quarkus/keycloak/pep/runtime/KeycloakPolicyEnforcerAuthorizer.java#L159

If users or Quarkus or Quarkiverse extensions add these checkers, they are not java.security.Permissions. You must not use getPermissions for checking permissions because this addPermissionChecker and checkPermission exists in Quarkus Security API very long time. I'd like users to realize it, if you don't think there is a risk, I can respect that.

[sberyozkin]

Thanks @michalvavrik I'll think about your comment and reply a bit later, this PR is not essential for the next release