Hi Ryan
I understood the thrust of your initial argument and agree with it (have
been reading the thread from your first post =)
I was not clear in my earlier post -- My points are only about secure vs.
insecure URLs as I feel they are more aptly secured by the Servlet
container. Again if we can work out a good case for moving this to JAX-RS
too (portability?), I'll take the fight to the Servlet EG ;)
Dhanji.
On 9/27/07, Ryan McDonough <ryan_at_damnhandy.com> wrote:
>
> 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
>