On Fri, Mar 4, 2016 at 2:44 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> The embedded password annotation idea was intended only for test cases and
> RAD prototypes.
>
Indeed, that's also how I described your proposal here:
http://arjan-tijms.omnifaces.org/p/whats-new-in-java-ee-security-api-10.html#9
"The embedded identity store allows authentication data to be stored
directly in the annotation. This type of store is typically used
exclusively for testing purposes."
> That being said it could be useful in conjunction with password aliasing
> (also a proposed feature).
>
Indeed, I hope we can still specify and implement that. An alternative that
was proposed by Rudy is "simply" EL enabling every or most annotation
attributes.
So you could do e.g.
@Credentials(callerName = "reza", password = "#{myFault.pass('reza')}",
groups = { "foo", "bar" })
Where "myFault" would resolve to a CDI bean provided by the user.
With EL 3.0 and its ELProcessor this is quite easy to add. See
https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/cdi/RememberMeInterceptor.java#L117
Kind regards,
Arjan Tijms
>
> 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>
>>> 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>
>>>>> 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>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 Hathttp://bill.burkecentral.com
>
>