Add support for Roles with permissions

[smsajid]

Description
Quarkus currently supports only role based security check. Need a mechanism to add permissions to roles and allow security check with permissions as well. A role can have permissions 'perm1', 'perm2', etc. Permissions can be dynamically added to roles. This allows more flexibility in security implementation and roles can be dynamically created by application.

Similar to @RolesAllowed, add annotation @PermissionsAllowed and other config based security settings.

[sberyozkin]

@smsajid is it related, #10988 ? Please also prototype some example (some test token content, etc) so that it become more obvious what your proposal is about

[smsajid]

Yea, looks like #10988 is similar proposal. I searched for an existing proposal to comment on. Wondering how I missed this. My proposal is inspired by http://shiro.apache.org/authorization.html as I have worked with shiro before and found it very powerful.

[MarcusBiel]

Any news here? PING.

[drubio-tlnd]

Any update on this topic ?
I did something similar in order to check entitlements, authorities etc. as it's done with @RolesAllowed with a custom interceptor but this could be a useful feature

[MarcusBiel]

The issue is now over one year old (taking into account the original ticket I used to report it). Still no update?

[mklueh]

Hi ✌️

[michalvavrik]

I found this issue while doing research on #10988 - I suggest that I impl. #10988 and give config option to link role with permissions. Everyone fine with that? ETA: end of January

[sberyozkin]

@michalvavrik Hi Michal, I've asked for the clarification in #10988

[michalvavrik]

Hi @sberyozkin ,

re #31345 (comment), I re-read your comments, most importantly this one #10988 (comment). It is clear that we can map roles to permissions on HTTP security policy level, but this configuration is exclusively used for path matching HTTP security policy. As you know, path matching security policy is applied before JAX-RS layer comes into action, therefore any role/permission set via this configuration properties won't ever be checked by the security annotations like @RolesAllowed or @PermissionsAllowed.

If path is secured for certain role, and the role has permissions, than there is no point using the annotation on resource method as the security check will be successful in 100 %. Can you give me a quick hint how are users going to use such a link? You don't need to go to the details of solution, just a line that shows me a way.

Thank you

[michalvavrik]

Now that I'm working on it, I also mentioned second important reason why it should be part of the Quarkus Security. Most of Auth config is now moving to the runtime (fingers crossed - #31800), adding this mapping to the vertx-http extension means I either have to add security identity agumentor even when there is no mapping, or make this mapping build time only. While if I put it to the Security extension, I could make IdentityProviderManagerCreator synthetic bean and only add this buildin permission agumentor only when needed. Sure, there are other patterns, but still would be most elegant.

[sberyozkin]

@michalvavrik

As you know, path matching security policy is applied before JAX-RS layer comes into action, therefore any role/permission set via this configuration properties won't ever be checked by the security annotations like @RolesAllowed or @PermissionsAllowed.

Sure so the same way RBAC can be enforced at the HTTP security policy level without using @RolesAllowed we'd enforce the permission based access control without @PermissionAllowed, so when, in the HTTP security policy, its role mapping config, we say this or that role implies this or that permission then it will activate the permission check implicitly.

What do you think ? HttpSecurityPolicy is there to let users avoid relying on the annotation but setting everything in the configuration, kind of similar to the keycloak authorization approach where you set the scopes in the configuration and it just worked without PermissionAllowed

[michalvavrik]

Alright @sberyozkin , that's perfectly fine solution. I completely misunderstood you previously. Thanks!

[michalvavrik]

Actually, now that I think about it, it makes perfect sense.

[sberyozkin]

Thanks @michalvavrik, indeed, if someone chooses using PermissionAllowed then they can use the current approach, with SecurityIdentityAugmentor, but with the policy configuration, they can do the annotation free control by associating roles with permissions.

But I wonder, should HttpSecuriry Policy configuration also allow specifying permissions only without mapping them to roles.
For example, AuthConfig#Map<String, PolicyConfig> rolePolicy which allows linking specific policies to specific roles and I suppose it is in PolicyConfig where we will map roles to permissions.

But lets say we use OIDC and HTTP securitty policy config and the policy is authenticated (no RBAC) and OIDC maps a token scope claim to String Permissions. That means we might also (additionally) need to have
AuthConfig#Map<String, PermissionConfig> permissionPolicy which in this case will link authenticated policy with a set of permissions, perhaps I can look into this specific update as part of the OIDC enhancement after you finish with this issue

[michalvavrik]

I'm going in the similar direction (basically I just put everything into PolicyConfig), but I'll open PR in next days and we can discuss it there. It is always easier to describe what is wrong/what should change than to design something from scratch. Glad we see it roughly similar, thanks @sberyozkin .

[michalvavrik]

@sberyozkin I iterated into this (still coding, no PR):

• for now I won't add HTTP policy that checks permissions allowed as I'm bit worried that users would be confused about difference between HTTP permission and identity permissions (that identity permission grants HTTP permission). TBH I'm quite worried that it already is too complicated according to Steph. We can add it little later.
• now I'd like to concentrate on mapping HTTP policy roles to permissions, my idea is it will work this way
  • via configuration properties you can say that any request that complies certain named HTTP Security policy will be granted certain permissions if it has roles xyz. So for example

quarkus.http.auth.policy.policy1.roles-allowed=**
quarkus.http.auth.policy.policy1.role1.grants-permissions=perm1,perm2

will grant permissions perm1 and perm2 to any authenticated request, whose SecurityIdentity has role1. (btw. @RolesAllowed("**") is same as @Authenticated)
It can be done quite conveniently, as there is already mechanism for HTTP Security policies to augment identity.
But you can do same for any role, e.g. you can say

quarkus.http.auth.policy.policy1.roles-allowed=user
quarkus.http.auth.policy.policy1.user.grants-permissions=perm1:action1
quarkus.http.auth.policy.policy1.admin.grants-permissions=write

which will grant any user with role user permission perm1 with action1 and if that user is also admin, he will be granted permission write.
And optionally, you can even specify your own permission class like this

quarkus.http.auth.policy.policy1.permission-class=javax.security.auth.AuthPermission

Please feel free to suggest changes, raise your objections, whatever :-)