Arjan,
I like the idea and I think it can be quite important for a lot of projects.
It can be used to define the rules somewhere else and not in the web.xml.
For example when you have an application with 100 screens and 10 user
groups, the config within web.xml becomes a burden.
So I see it not only as a way of dynamical defining the authorization but
also as an SPI for the authorization rules.
The question remains then if we need to foresee it in the Java EE Security
API or that it needs to be included in (a next version) JACC?
Or that we need to specify something because with a custom JACC module you
can achieve it already today.
best regards
Rudy
On 25 July 2016 at 18:37, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>
>
>
>
>
>