Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [es-dev] Authorization modules / Authorization rules
All,

I created some time ago a prototype that is based on CDI interceptors.  The Permission strings are based on what Shiro is using (so thus not use Permission that is marked for removal - JEP 411)

The permission isa string but typical it can represent some hierarchy 
order:read:* -> read all orders in the system
order:write:user -> update only orders you have created
order:*:* -> access and update all orders
*:*:* -> admin

or a simple string indicating a permission

readFile
writeFile


To secure a method, the following construct can be used

@RequiresPermissions("order:read:*") public List<Order> readAllOrders(); And users having a 'matching' permission are allowed to execute the method. ("order:read:*", or "order:*:*", or "*:*:*") The prototype also allows to create some complex 'voters' to determine if a user is allowed to execute a method, an example of such a voter is public class TestCustomVoter extends AbstractGenericVoter {

    @Inject
   @RequiresPermissions("order:read:*")
   private GenericPermissionVoter orderReadVoter;

    @Inject
   @RequiresPermissions("order:*:manager")
   private GenericPermissionVoter orderManagerVoter;


    @Override
    protected void checkPermission(AccessDecisionVoterContext accessDecisionVoterContext, Set<SecurityViolation> violations) {
        orderManagerVoter.checkPermission(accessDecisionVoterContext,violations);
        if (!violations.isEmpty()) {
            // not a manager, check if user has access
            violations.clear();
            orderReadVoter.checkPermission(accessDecisionVoterContext,violations);
           
        }
    }
} This is part of the Octopus security framework that I created and can be found here : https://github.com/atbashEE/atbash-octopus Rudy

On Thu, 23 Sept 2021 at 16:37, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

One of the things we left open for Jakarta EE Security 1.0 was the authorization topic, prioritising authentication first (which resulted in the HttpAuthenticationMechanism and IdentityStore).

I did a prototype back then for an authorization module, but we didn't discuss it further after running out of time.

In this article I'm discussing this prototype: 


For Jakarta Security 3.0 this topic is on the plan again: https://projects.eclipse.org/projects/ee4j.es/releases/3.0

Thoughts?

Kind regards,
Arjan

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev

Back to the top