Provide more flexible and usable REST security and (JCR) session configuration and handling

Currently we can (only) configure REST security on a mount level and/or on a sitemap (item) together with a pipeline SecurityValve.
However for non-sitemap based REST mounts the latter isn't available.

The above is far too course-grained.
A typical use-case would be a REST mount which allows anonymous GET|HEAD|Options (for all or some resources) but secured access for PUT|POST|DELETE (for all or some resources).
And some of these operations might require specific roles while others might require different roles.

We probably need be able to configure (additional/stronger) security constrains on resource endpoint methods directly, preferably using annotations.
However, JAX-RS (1.1) doesn't provide a spec based solution for this, other than providing access to a SecurityContext if desired within the resource method.

One option might be using a custom (CXF) jaxrs invoker as explained here: http://cxf.apache.org/docs/jax-rs.html#JAX-RS-Custominvokers and then inspecting security annotations before actually invoking the Resource method.

Another/additional minimal effort solution might be adding optional role requirements on a (REST) mount for each HTTP method itself (e.g. like for GET|HEAD|OPTIONS undefined or "anonymous", for PUT|POST|DELETE enumeration of required roles).

Please investigate and advise on/propose a pragmatic flexible and easy to configure/use solution for this.

Another related "issue" is how the current demosuite uses (requires) stateful jcr sessions.
I think that (by default) all JCR interactions should not use (need) stateful sessions, only on the fly created new sessions.
AFAIK the stateful sessions really are needed for features like faceted search caching, but as long as that isn't needed nor should we need stateful jcr sessions (from REST) then.

HTTP Session binding is of course another matter: as long as we haven't integrated OAuth we'll have to rely on (JAAS) authenticated HTTP sessions.
And if no Http Session replication between cluster nodes is enabled, using sticky sessions will be needed as well.
JCR sessions however should be possible to (re)create and close for each request needing only credentials stored in the HTTP Session.