>
> 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.
That is a good reason to put it in Java EE Security API.
Rudy
On 18 August 2016 at 12:17, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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.omni
>>> faces.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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>