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)?
* 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?
> > 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.
What I am proposing is only that JAX-RS's OPTIONS response shall not "lie":
If a request is authenticated -independent of the used authentication
technology- there is a "Principal" instance living on the Server side. If
that principal is not allowed to enter a method thanks to @RolesAllowed, or
@DenyAll, it would be a pure lie that OPTIONS's Allow header contains that
method -- since that method would simply be as "unallowed" as if it would
not exist at all.
So I do not do any custom or fancy stuff. I do pure http. And to do this, I
need the possibility to find out in a post-matching filter what JAX-RS
resource method (Java method) actually will be called, so I can check that
for security annotations. Or, if we cannot agree upon such an interface,
JAX-RS must do that OPTIONS reduction on its own (what would be my favour
solution as it does absolutely no harm and is 100% correct use of http).
Regards
Markus