On Oct 28, 2012, at 1:56 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> Experts,
>
> I'd like to ask you to comment this feature proposal http://java.net/jira/browse/JAX_RS_SPEC-304 for improved integration of JAX-RS with EJB security annotations. :-)
I don't think that the Allow header is conceptually tied to authorization. AFAIK it informs about general server or resource capabilities, orthogonal to any given principal.
I think it would be wise to check back on the HTTP list, first.
Jan
>
> Regards
> Markus
>
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Samstag, 27. Oktober 2012 18:10
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Integration of Java EE security annotations with JAX-RS 2.0
>
> I don't think that's something we would be able to specify in JAX-RS 2.0 timeframe.
>
> Marek
>
> On Oct 27, 2012, at 4:01 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
>
>
> Experts,
>
> possibly I (again) missed an already finished discussion (I am happy if you send an archive URL in that case)…:
>
> I want to ask whether there are plans to integrate JAX-RS 2.0's automatic creation of "Allow:" (as a rection to OPTIONS) with Java EE's security annotations like "@RolesAllowed"?
>
> Example:
>
> Given the following EJB-integrated JAX-RS resource…
>
> @Path("/stats") @Stateless class UserStatistics {
> @GET @RolesAllowed("Administrators") public getSomeInteresticMetrics() {…}
> }
>
> …will the automatic OPTIONS response provided by a compliant JAX-RS implementation have to automatically omit "GET" in case the caller is not authenticated and authorized as an Administrator?
>
> If not, this would be a really brilliant addition the the EJB-integration chapter of the spec, as it allows client applications to prevent a GET invocation completely, hence show a "disabled" GUI or suppress a senseless network roundtrip. :-)
>
> Regards
> Markus
>