@RolesAllowed should just be required to support. But, I stress again,
@RolesAllowed is just half of the problem...
BTW, IMO, the NIO and SSE stuff is borderline a waste of effort both for
the spec lead and for us implementers that have to suffer the TCK. I
just don't think you'll have a lot of people using either feature... Let
the flames begin.
On 3/3/2016 12:39 PM, markus_at_headcrashing.eu wrote:
> 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
>>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com