With the proposed work there's various levels of checks, from simple to more elaborate:
There's the good old @RolesAllowed/Permitted which checks for a single role:
@RolesPermitted("foo")
public void someMethod()
There's the proposed EL based authorization annotation:
@IsAuthorized("hasRoles('Manager') && schedule.officeHours")
public void someMethod()
And there's the custom authorization rules:
@RolesPermitted("something")
public void someMethod()
OR
@WebServlet...
@ServletSecurity(@HttpConstraint(rolesAllowed = "something"))
And then:
@Override
public Boolean postAuthenticatePreAuthorizeByRole(Permission requestedPermission, Caller caller, SecurityConstraints securityConstraints) {
return getRequiredRoles(securityConstraints.getPerRolePermissions(), requestedPermission)
.stream()
.anyMatch(role -> isInRole(caller.getCallerPrincipal().getName(), role));
}
}
(please don't look at the exact annotation and methods names too much, as they are just placeholders)
The EL based annotation is for more elaborate, but still relatively simple checks. The permission checks (role or url access), always go to the authorization module, which is currently in Java EE either a proprietary system (such as Elytron in WildFly), or standard JACC (such as in Payara and GlassFish).
In Java EE the JACC provider can be replaced fully, but it's an obscure and tedious job and few companies do this (a recent customer of Werner, whom I know as well, do use this, but they are the exception).
So in EE Security 1.1 the plan is to let the user add smaller and simpler modules that are called by the default JACC provider.
These modules can make programmatic decisions, and are essentially much like the EL that Reza proposed, but 1) are a Java method, and 2) can be added/replaced/removed independent of the code that is being protected. Such small rule modules can even be added from outside the application (i.e. added at the container level).
Kind regards,
Arjan
_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/es-dev