[jax-rs-spec users] [jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

From: Markus KARG <>
Date: Tue, 6 Nov 2012 19:53:17 +0100

> > I wonder how a client shall find out whether or not to show / hide
> > particular GUI items (e. g. menu items directly related to the access
> > rights of the current user) if the client cannot find out the access
> > rights by pure http means. Is your proposed solution really to _not_
> > use pure http means but build a particular application-specific
> > protocol ontop? If yes, what good for is OPTIONS then?
> To be honest I'm not sure how one can write a practical application by
> depending on the list of verbs returned with OPTIONS

Well... AFAIK the sole use of OPTIONS *is* to tell a generic client what
methods are allowed to be called. If your concerns would be true, there
would be no sense to enforce OPTIONS in the http protocol at all.

> > I mean, if it reports a method that the current user must never
> > invoke?
> I just think it would overload OPTIONS.


> IMHO the better approach is to offer a user/role-specific view,
> example, a user logs in, and the server picks up say admins.jsp to
> present a view. It is only the issue with monolitic UI frontends, isnt
> it ?

Agreed, but how does the current JAX-RS API draft support this alternative

> Also, IMHO, enforcing RBAC with @RolesAllowed is the most basic
> approach, a number if options exist to enforce the method-level
> authorization. Thus it seems to me it is out of scope for JAX-RS, given
> that the 'responsibility' of the spec is to promote the ideas that can
> lead to interoperable applications being created

Well, it is the approach Java EE defines, and JAX-RS is part of Java EE. I
do not say it must be the sole aproach, but it should be the mandatory basic