The embedded password annotation idea was intended only for test cases and RAD prototypes. That being said it could be useful in conjunction with password aliasing (also a proposed feature).
> On Mar 3, 2016, at 8:24 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
> Excellent, that's what we need. BTW, why would you ever specify username password in an annotation? That is just bizarre.
>
>> On 3/3/2016 5:24 PM, arjan tijms wrote:
>> On Thu, Mar 3, 2016 at 10:40 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>> @RolesAllowed should just be required to support. But, I stress again, @RolesAllowed is just half of the problem...
>>
>> I take it you're referring to this here:
>>
>>> 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.
>>
>> Since JAX-RS is layered on top of Servlets, I'm eager to learn why defining the authentication mechanism in web.xml would presumably not be good enough.
>>
>> Note that there's also a programmatic variant to register an equivalent to what you can specify in web.xml via the AuthConfigFactory. In JSR 375 we're adding another variant of that based on CDI and annotations.
>>
>> For an example see here: https://github.com/javaee-security-spec/soteria/blob/master/test/app-mem-basic/src/main/java/test/Servlet.java#L17
>>
>> These work quite well with JAX-RS. For an earlier prototype see e.g. this article: http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>>
>> We're using something quite close to that in practice for the API of zeef.com.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>>
>>> 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
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com