[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [es-dev] Authorization modules / Authorization rules
|
Hi,
On Friday, September 24, 2021, Rudy De Busscher <
rdebusscher@xxxxxxxxx> wrote:
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)
I think the Permission class itself is not removed, just as Principal and Subject it is part of a small group of classes that are kept.
Interceptors are somewhat of a different, though related, issue.
Authorization rules here are about simplifying the existing Jakarta Authorization modules, such that eg the existing web.xml constraints and the existing httpServletRequest.isUserInRole can be made more flexible.
Kind regards,
Arjan
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 |
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:
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
