Hi,
Up till now we've mostly been looking at the authentication epic, and even
though that's not entirely finished yet (the multi identity store proposal
and various multi authentication mechanism proposals are still open), it
may be a good idea to start looking at simplifying authorization.
To that end I've been prototyping an initial proposal for an authorization
mechanism or authorization module (name still TBD).
For the long story:
http://arjan-tijms.omnifaces.org/2016/07/simplified-custom-authorization-rules.html
Shorter story:
An application provided CDI bean that implements the AuthorizationMechanism
interface, with various methods that are called by the container's
authorization code (policy) at various moments.
E.g.
@ApplicationScoped
public class CustomAuthorizationMechanism implements AuthorizationMechanism
{
@Override
public Boolean postAuthenticatePreAuthorizeByRole(Permission
requestedPermission, Caller caller, SecurityConstraints
securityConstraints) {
return
getRequiredRoles(securityConstraints.getPerRolePermissions(),
requestedPermission)
.stream()
.anyMatch(role ->
isInRole(caller.getCallerPrincipal().getName(), role));
}
}
Here:
requestedPermission - the permission being asked for, e.g. "access
/foo/bar.xhtml using GET"
caller - the caller's authentication related data, the caller principal,
the roles, and the raw other principals
securityConstraints - the constraints as parsed from web.xml (and
corresponding annotations) as well as from EJB's ejb-jar.xml (and
corresponding annotations)
Return values:
null - no decision, let default algorithm handle the permission
true - requested permission granted
false - requested permission not granted
In the example above "isInRole" is a custom method using whatever logic the
application needs to determine if the caller has a given role.
This authorization mechanism is called to determine access to URLs, as well
as for determining the outcome of HttpServletRequest.isUserInRole,
@RolesAllowed, and of course JSR 375's own future
SecurityContext.isCallerInRole.
Open questions are e.g. naming; authorization mechanism vs authorization
module? and using methods vs events?
mechanism and methods are closer to what authentication is using, but here
module and events may look more natural.
Thoughts?
Kind regards,
Arjan Tijms