Hi Rudy,
Thanks for your reply ;) See comments inline below:
On Thu, Aug 18, 2016 at 11:29 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> 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.
>
Hmmm, indeed, that would be another rather innovative (for Java EE)
approach ;)
The authorization module/mechanism has access to the constraints/rules
parsed from web.xml and annotations, but it of course doesn't have to use
these or doesn't have to use these exclusively.
In short, simply having a hook available for developers would open up a
world of new possibilities for both developers as well as extension
libraries.
> So I see it not only as a way of dynamical defining the authorization but
> also as an SPI for the authorization rules.
>
Indeed ;)
> 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?
>
This particular approach is too high level for JACC I think which operates
at a much lower level. Just as the identity store and authentication
mechanism that we defined here were too high level for JASPIC.
This was a question though we also struggled with earlier. Do we start a
JSR 375 at all, since ultimately everything we do is either authentication
or authorization, and JASPIC resp. JACC already do that. At long last it
was (more or less) decided to keep JASPIC low level, and build the higher
level CDI based and Servlet specific types in JSR 375.
> Or that we need to specify something because with a custom JACC module you
> can achieve it already today.
>
True, although in practice almost nobody writes these since it's far too
much work for even the simplest of things (you basically have to code up
all things that you would normally assume a container would do), and a
portable application can't easily use it, since you need to install the
JACC module into your server somehow in some not rarely obscure way.
With this proposal, a developer doesn't have to write hundreds of lines of
code and implement a state machine, life cycle manager, configuration
collector etc, but only a single method that asks for an outcome. And most
importantly (as per the main goal of JSR 375) nothing application server
specific would have to be done.
The new interface would also technically not be tied strongly to JACC. It's
just a CDI bean that gets consulted by whatever system when it want to make
an authorization decision. Of course for Java EE and specifically for the
RI and Payara the no brainer way to implement it would be via a JACC
provider that's by default installed (just as the Soteria main jar is by
default installed).
It would greatly help though if JACC got a MR where it allowed a classic
JACC provider to be installed in a per web app fashion. That would greatly
simplify matters for vendors implementing JSR 375 and for to test Soteria
on different servers. I already send a proposal for that to the JACC list.
Kind regards,
Arjan Tijms
>
> 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(securityConst
>> raints.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
>>
>>
>>
>>
>>
>>
>