On 11/17/2012 4:55 AM, Markus KARG wrote:
>> I'd encourage to not try to get JAX-RS runtime deal with the diff level
>> responsibilities - and to be honest this is my main objection. I know
>> you asked for the ESB-specific module only to support it - my concern
>> would be people will request it be supported across the all JAX-RS
>> integration modules. Writing and testing a filter which can easily
>> check @RolesAllowed is easy - I can share the code from the existing
>> CXF interceptor which does it
>
> I totally agree, but I want to note that it is not possible to write such a
> filter in pure JAX-RS 2.0 (maybe you can tell me how, I did not find a
> possibility to get the java.lang.reflect.Method at which I can obtain the
> @RolesAllowed annotation)
See:
https://github.com/resteasy/Resteasy/tree/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/interceptors
RoleBasedSecurityFilter/Feature.java
Assumes that you're running in a servlet container.
> and in fact I *do* see JAX-RS to be the perfectly
> right level of *API* to *define* it (in the sense of "defining API" in
> contrast to "fulfilling implementation"). To say it clearly, this does not
> mean that a JAX-RS container must *implement* it in the sense of
> do-it-yourself, but what I expect actually is that a JAX-RS enabled web
> server comes with an optimized JAX-RS container that simply offloads the
> filtering of the Allows-Header to the lower level core server (i. e. *the
> server* does that checks e. g. by applying the filters we talked about -- as
> the @RolesAllowed annotation is static information, that core server can set
> up static code at deployment time inside of its own pre-JAX-RS routine phase
> to do this). For Java SE I would simply say it is optional, so it is up to
> the JAX-RS vendor to write additional code or not. But, as the application
> vendor *solely* writes applications following the JAX-RS specification
> (without any knowledge about the deeper levels), this spec *must* tell that
> in the Java EE scenario, @RolesAllowed MUST have effect in the reduction of
> the Allow-header's values -- independent of the implementor's choice to do
> this in the JAX-RS container, or offload it to the core server (which
> possibly provides some additional optimization benefits for full-stack
> providers).
>
I haven't followed this conversation, but you're specifying a custom
protocol? Because I'm pretty sure Allow header has no relationship with
main security protocols.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com