You still miss the point. All JAX-RS implementations already support
@RolesAllowed. My proposal targets upon unification of the API to
enable it. Not more. Not less. Your solution targets on providion an
ALTERNATIVE implementation outside of the JAX-RS container, which is
out-of-scope of JSR 370 for good reason: The container MUST forward
security tasks to the Java EE server product once bundled withat that,
so it MUST know about @RolesAllowed. You solution would enforce that
it becomes impossible to run the same JAX-RS application unchanged in
Java SE and Java EE environments, which is a clear target of the
JAX-RS API and particularly my proposal.
Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
> It's not really a proposal, it's just something user can do, and can do
> today. It's just like when you use JPA in a JAX-RS resource. People do that
> all the time, yet JAX-RS doesn't need be bundled with an implementation of
> the JPA spec on Java SE.
>
> And there's more. There's BeanValidation, really great to use with JAX-RS,
> but also not needed to bundle with JAX-RS. And EJB, with pooled and
> transactional beans, work great from JAX-RS, but no need to bundle it, etc.
>
> Of course individual vendors may bundle all that, but then you have
> essentially Java EE, or actually Java EE. It's more or less what TomEE
> does. It runs on Java SE, bundles all the Java EE specs, and then it
> actually IS Java EE ;)
>
> But I'd like to stress that Interceptors here are not necessarily the way
> to make the *common annotations* @RolesAllowed work in JAX-RS. Interceptors
> are an alternative way, by which *the user* can do pretty much what a
> common annotations @RolesAllowed backed by the JAX-RS spec would do, but
> *without any involvement from JAX-RS*. It's completely transparant to
> JAX-RS. Just like a user can use a Servlet Filter today without the spec
> needing to have any knowledge of what the user does in that filter.
>
> In order to give meaning to the *common annotations* @RolesAllowed, the
> JAX-RS spec should indeed say something about it, and JAX-RS
> implementations have to provide some code for that, but it's relatively
> simple if you just use existing Servlet APIs.
>
> In that regard, a common annotations @RolesAllowed and a potential
> Intercepter based @RolesAllowed are completely opposites. In the first case
> you just have the annotation, and each spec must interpret it individually
> and act on it. While in the latter case the Interceptor comes with code
> that can be applied to everything that's a CDI bean or other managed bean
> to which Interceptors can be applied. The spec that uses that bean does not
> have to be aware of what those Interceptors do.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> On Thu, Mar 3, 2016 at 11:24 PM, <markus_at_headcrashing.eu> wrote:
>
>> That would impose that JAX-RS comes bundled with an implementation of the
>> Interceptors spec on Java SE, which is actually intended for Java EE:
>>
>> "Interceptors are used ... on instances of Java EE components and other
>> managed classes"
>>
>> As that will not be the case, your proposal won't work.
>>
>> -Markus
>>
>>
>>
>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>
>> Interceptor spec Interceptor ;) Using java.interceptor.Interceptor
>>>
>>> Assumes of course that the JAX-RS resource is also a CDI bean, which is
>>> why
>>> I mentioned "especially if JAX-RS also further aligns with CDI."
>>>
>>> On Thu, Mar 3, 2016 at 6:31 PM, <markus_at_headcrashing.eu> wrote:
>>>
>>> So with "interceptor" you actually mean "JAX-RS Interceptor"?
>>>>
>>>>
>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>
>>>> Depends, one can keep adding things to Java SE until it's essentially
>>>> Java
>>>>
>>>>> EE anyway, but regardless how is that a problem?
>>>>>
>>>>> If I have a JAX-RS application, and I apply my very own
>>>>> FooBarInterceptor,
>>>>> and I run it on Java SE where I don't also add CDI, then it won't get
>>>>> called. That's pretty much the entire idea. Nothing for the JAX-RS spec
>>>>> to
>>>>> worry or care about is it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 7:55 PM, <markus_at_headcrashing.eu> wrote:
>>>>>
>>>>> You miss the point that JAX-RS does not mandate that CDI must be used on
>>>>>
>>>>>> Java SE. So the interceptor will never get called.
>>>>>>
>>>>>>
>>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>>
>>>>>> On Tue, Mar 1, 2016 at 11:12 PM, <markus_at_headcrashing.eu> wrote:
>>>>>>
>>>>>>
>>>>>>> The JAX-RS specification says that JAX-RS can be used not only within
>>>>>>> Java
>>>>>>>
>>>>>>> EE but also as a standalone technology ontop of Java SE. To make a
>>>>>>>> JAX-RS
>>>>>>>> application work correctly in both environments (hence: without JSR
>>>>>>>> 375
>>>>>>>> beneath) the JAX-RS specification either must declare that JSR 375 is
>>>>>>>> to
>>>>>>>> be
>>>>>>>> bundled with JAX-RS on Java SE, or it must define a different way to
>>>>>>>> declare security with in turn enables JSR 375 on Java EE but may use
>>>>>>>> any
>>>>>>>> other technology on Java SE.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> JAX-RS doesn't have to know about an Interceptor based @RolesAllowed,
>>>>>>> does
>>>>>>> it?
>>>>>>>
>>>>>>> Such an interceptor can be applied to every method to which
>>>>>>> Interceptors
>>>>>>> can be applied and it does what it does then. No need for JAX-RS to be
>>>>>>> aware of what it exactly does, so no need for JAX-RS to define a
>>>>>>> different
>>>>>>> way for when JAX-RS runs on top of Java SE.
>>>>>>>
>>>>>>> It's not that different from using say the @Transactional interceptor.
>>>>>>> Anyone can apply that to a method, and if that method is applicable
>>>>>>> for
>>>>>>> interception a transaction it will be transactional. But JSF, MVC,
>>>>>>> JAX-RS
>>>>>>> and what have you do not all need to go duplicate JTA or provide JTA
>>>>>>> delegation mechanisms, do they? They only need to use CDI beans, which
>>>>>>> automatically provides Interception, and then the actual interceptors
>>>>>>> people put on their methods is not the concern of the spec that just
>>>>>>> uses
>>>>>>> CDI and/or Interceptors.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>>>>
>>>>>>>> If it's an Interceptor spec interceptor, will it not run regardless
>>>>>>>> of
>>>>>>>> what
>>>>>>>>
>>>>>>>> the JAX-RS spec otherwise says about security?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 1, 2016 at 10:31 PM, <markus_at_headcrashing.eu> wrote:
>>>>>>>>>
>>>>>>>>> To clarify my proposal, I actually don't care about *which*
>>>>>>>>> annotation
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> getting used, as long as JAX-RS 2.1 specifies one common solution
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>>> ALL
>>>>>>>>>> implementations. Certainly my vote would be for "enable
>>>>>>>>>> @RolesAllowed
>>>>>>>>>> by
>>>>>>>>>> default" as it is what currently everone simply would expect to
>>>>>>>>>> work
>>>>>>>>>> out
>>>>>>>>>> of
>>>>>>>>>> the box.
>>>>>>>>>>
>>>>>>>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As we're streamlining security for the entire platform via JSR 375,
>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>>> would
>>>>>>>>>>> not be a fan of having another JAX-RS (or any spec for that
>>>>>>>>>>> matter)
>>>>>>>>>>> specific annotation or other artefact to deal with security.
>>>>>>>>>>>
>>>>>>>>>>> One of the plans for JSR 375 is to have an Interceptor spec/CDI
>>>>>>>>>>> based
>>>>>>>>>>> @RolesAllowed equivalent, which may be more consistent, especially
>>>>>>>>>>> if
>>>>>>>>>>> JAX-RS also further aligns with CDI.
>>>>>>>>>>>
>>>>>>>>>>> For the existing common annotations version of @RolesAllowed I
>>>>>>>>>>> would
>>>>>>>>>>> definitely go for "Enable it by default.". These things should
>>>>>>>>>>> Just
>>>>>>>>>>> Work,
>>>>>>>>>>> and not require any "activation" really (some EJB containers had
>>>>>>>>>>> the
>>>>>>>>>>> same
>>>>>>>>>>> problem, a need to activate @RolesAllowed, really inconvenient and
>>>>>>>>>>> hurting
>>>>>>>>>>> portability of apps).
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 1, 2016 at 6:28 PM, <markus_at_headcrashing.eu> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Experts,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I hope you're in the mood for another small spec clarification in
>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>> hope
>>>>>>>>>>>> to further align Jersey, WebSphere, CXF and RestEasy. :-)
>>>>>>>>>>>>
>>>>>>>>>>>> The current Jersey manual says that it will respect role-based
>>>>>>>>>>>> security
>>>>>>>>>>>> annotations (@PermitAll, @DenyAll, @RolesAllowd; according to JSR
>>>>>>>>>>>> 250
>>>>>>>>>>>> "Common Annotations for the Java Platform") as soon as a
>>>>>>>>>>>> Jersey-specific
>>>>>>>>>>>> filter is EXPLICITLY enabled by means of JAX-RS feature config
>>>>>>>>>>>> API.
>>>>>>>>>>>> If
>>>>>>>>>>>> I
>>>>>>>>>>>> understood the WebSphere manual correctly, I respects these
>>>>>>>>>>>> annotations
>>>>>>>>>>>> BY
>>>>>>>>>>>> DEFAULT. According chapter 36 of its manual, it seems as if
>>>>>>>>>>>> RESTeasy
>>>>>>>>>>>> wants
>>>>>>>>>>>> EXPLICIT enabling by Servlet web.xml. CXF on the other hand
>>>>>>>>>>>> apparantly
>>>>>>>>>>>> wants the deployer to enable an interceptor EXPLICITLY. So all
>>>>>>>>>>>> those
>>>>>>>>>>>> JAX-RS
>>>>>>>>>>>> products process these annotations, but each has a different way
>>>>>>>>>>>> to
>>>>>>>>>>>> enable
>>>>>>>>>>>> it. Looking through the eyes of an ISV, this is real
>>>>>>>>>>>> pain-in-the-*
>>>>>>>>>>>> since
>>>>>>>>>>>> security is a must-have in all non-trivial products and nobody
>>>>>>>>>>>> wants
>>>>>>>>>>>> to
>>>>>>>>>>>> provide four different configs for the same off-the-shelf app.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to suggest that the spec 2.1 defines ONE COMMON way
>>>>>>>>>>>> which
>>>>>>>>>>>> enables
>>>>>>>>>>>> security on ALL JAX-RS products.
>>>>>>>>>>>>
>>>>>>>>>>>> I have two proposals:
>>>>>>>>>>>>
>>>>>>>>>>>> (a) Enable it by default. It should not do any real harm
>>>>>>>>>>>> regarding
>>>>>>>>>>>> backwards compatibility. This way, nobody has to worry about
>>>>>>>>>>>> security
>>>>>>>>>>>> besides adding above role annotations.
>>>>>>>>>>>>
>>>>>>>>>>>> (b) Enable it explicitly by adding @Secured on the Application
>>>>>>>>>>>> class. I
>>>>>>>>>>>> think this is ugly as the existence of above annotations already
>>>>>>>>>>>> imply
>>>>>>>>>>>> that
>>>>>>>>>>>> security is wanted.
>>>>>>>>>>>>
>>>>>>>>>>>> As all products already support the functionality, we just need
>>>>>>>>>>>> to
>>>>>>>>>>>> agree
>>>>>>>>>>>> upon a SINGLE way to enable it. I think people simply expect this
>>>>>>>>>>>> in
>>>>>>>>>>>> 2.1.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> -Markus
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>