Dhanji,
I put a post up a few days ago on this topic here:
http://www.damnhandy.com/2007/09/22/some-thoughts-on-securing-web-resources/
The distinction in what I'm proposing is that JAX-RS can declare security
constraints for a particular representation rather than a URI. The servlet
spec only secures the URI and thus is you needed to provide different rules
for different representations, you'd need to break those out in to multiple,
distinct URIs. With this proposal, I'm hoping to avoid that so you have a
single URI, but the security rules could differ depending on the type of
representation you are requesting.
The ideas suggested here borrow a lot from the servlet spec, and that is
intentional. The idea here is keep it both container independent and offer
more flexibility than what the servlet spec current offers. You could
consider it a hybrid of EJB & servlet security.
As far as transparently clustered internal nodes, I haven't given it much
thought yet.
Ryan-
On 9/27/07, Dhanji R. Prasanna <dhanji_at_gmail.com> wrote:
>
>
>
> On 9/25/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> >
> > Hi Ryan,
> >
> > I can imagine this is something that would be very useful to specify
> > per-application when RolesAllowed is used. For example, when testing use
> > HTTP and not HTTPS. Or because the deployer wants control over the
> > transport security and does not trust the developer to specify it
> > correctly in the application.
>
>
> Hmm. What about transparently clustered environments (as in REST)? Does
> the data typically go over HTTPS even on the internal nodes? Am curious...
>
> Should there be some precedence in that if the application says NONE,
> > but the transport is CONFIDENTIAL then the runtime can continue, namely
> > should the application care? or should redirection happen to the
> > insecure URI?
>
>
> This is all container dependent IMO. Are you suggesting that JAX-RS
> inspects the protocol to ensure it was secure? Like a double-guard...
> My first thought--I would just entrust it to the security URI mapping
> available in Servlet.
>
> However, to make portable JAX-RS applications (between servlet and say,
> restlet containers ;) this may be an interesting use case. For example, the
> JAX-RS app could reconfigure its servlet web-xml on-the-fly to add
> particular security constraints on certain URIs. I'll bring this up in the
> Servlet EG (the plan is for programmatic access to web-xml anyway) if you
> guys think it is worthwhile?
>
> However, I still think a blanket security URI mapping, at the container
> level (a la Acegi's ant-style paths), is more elegant and simple.
>
> Do you think there will be use-cases where NONE, INTEGRAL (whatever that
> > is!), and CONFIDENTIAL transports will be used in the same application?
>
>
> INTEGRAL refers to non-repudiation of the data transaction. CONFIDENTIAL
> means nobody else observed it. The latter is a stronger level. In practice I
> believe either is generally implemented over SSL.
>
> IIRC, these are Servlet-only (not Java EE -wide) transport constraints.
> Are we then deciding to adopt the Servlet standard for this?
>
> Dhanji.
>
>
--
Ryan J. McDonough
http://www.damnhandy.com