As time is scarce and manpower is not for free, my proposal was to
simply define a default API for the implementations we actually have
in the products already. It would make ISVs lives much easier if we
don't have to add container-specific enablers.
Zitat von Sergey Beryozkin <sberyozkin_at_talend.com>:
> Markus, I was only referring to Bill's idea that it would be good to
> have some standard way to do Basic Auth/etc.
> I'm not sure how far/if at all we can go about supporting
> @RolesAllowed in 2.1 - there are pieces of work to be done around
> the proposed NIO/etc API improvements (proposed by the spec leads),
> minor items proposed by us, and here I'd indeed support having
> something standard, loosely typed authentication API introduced
> given that indeed Basic Auth is only one of several options these
> days.
>
> @RolesAllowed is similar to Basic Auth, it is kind of outdated
> really, and other forms of the access control should be taken into
> the consideration, it was proposed by one of experts/users before
> that @Scopes (OAuth2 access token related) get introduced, etc.
>
> Sergey
> On 02/03/16 18:58, markus_at_headcrashing.eu wrote:
>>
>> May I interpret you answer as "Yes, JAX-RS 2.1 MUST specify a
>> common way to enable @RolesAllowed, and CXF will implement it ASAP"?
>>
>> Zitat von Sergey Beryozkin <sberyozkin_at_talend.com>:
>>
>>> On 01/03/16 18:11, Bill Burke wrote:
>>>> I'd like to see some clarification on this too. If your jax-rs
>>>> service is an EJB, I believe the spec says @RolesAllowed is
>>>> supposed to be honoured, but JAX-RS has no other annotations to
>>>> define things like transport requirements (Is SSL required), nor
>>>> does it define a way to specify an authentication protocol
>>>> (BASIC, FORM, CERT, SAML, OIDC, etc.). So, you end up still
>>>> having to define security constraints and login config within
>>>> web.xml.
>>>>
>>>> Security is very undefined on the client. There's no standard
>>>> way of doing BASIC auth. BASIC auth still seems to be used even
>>>> though OAuth and other token based architectures are starting to
>>>> be prevelant.
>>>>
>>> The users start driving it :-), opened few minutes ago
>>>
>>> https://issues.apache.org/jira/browse/CXF-6817
>>>
>>> The only standard way I know of is to create an Authorization
>>> header manually and set it on the target
>>>
>>> Cheers, Sergey
>>>
>>>> On 3/1/2016 12: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
>>>>>
>>>>
>>
>>
>>