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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>