On 11/20/2012 3:29 PM, Markus KARG wrote:
> Bill,
>
> thank you for posting this solution. But I have some questions to understand
> the code:
>
>>>> 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.
>
> * This code is not vendor-agnostic as it contains ResteasyProviderFactory.
> As I am an ISV, I do not like to bundle another vendor-specific filter for
> every possible JAX-RS container on the market with my application
> (effectively breaking WORA). Would it be possible to replace
> ResteasyProviderFactory by a pure JAX-RS thing (otherwise your code would be
> a good proof that it is impossible for an end user to write such a filter,
> hence there must be a JAX-RS solution be added to the spec)?
>
Whoops. Good catch. You can inject SecurityContext via @Context. I'll
make that change. Not sure why I did it that way to begin with. Maybe
its just because it evolved from really old code.
> * I do not understand how the @RolesAllowed, @DenyAll and @PermitAll
> annotations found at different JAX-RS resource methods make their way into
> your filter constructor. Your code looks to me like if the annotations would
> be statically linked to the filter for all JAX-RS methods, effectively being
> application-wide, while actually must instead be working
> per-resource-method. Is that a JAX-RS feature I did miss in the spec?
>
RoleBasedSecurityFilter is a per-method filter. Look at
RoleBasedSecurityFeature.java
>>> 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.
>
> No I am not proposing a custom protocol but simply applying the very core
> idea of what OPTIONS's "Allow" is intended to be used for: Telling the
> client what methods are allowed to be called by this client. The http RFC
> does not limit the sources where this information is taken from. JAX-RS
> currently simply assumes that the pure existence of a resource method turns
> this into a valid member of the "Allow" header, but the http RFC allows us
> to further limit the set of members of the "Allow" header. In my proposal, I
> simply say I further reduce this set in case of authenticated requests.
>
Sorry, but I think you are overloading Allow. BTW, I think the whole
default behavior for OPTIONS and Allow is junk anyways. I just find it
very hard to believe anybody could get anything useful out of so little
information. I even think the OPTIONS method in HTTP is junk and
useless too. In the real world you are going to be provided with a link
to metadata that describes the service (or set of services) (i.e. a
yucky, icky WADL document). Or, your media type will be self describing
(i.e. HTML).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com