LOL! Now I don't even know what I mean! Anyway, my thinking was pretty much
you've laid out below. The only driver for putting these things into JAX-RS
was for common way to access these features outside of a servlet container.
I don't have a strong case for moving this to JAX-RS other than
portability, so perhaps it's appropriate to leave this one for the servlet
eg.
Ryan-
On 9/27/07, Dhanji R. Prasanna <dhanji_at_gmail.com> wrote:
>
> Re-reading that, it is still not clear what secure could mean!
>
> secure == CONFIDENTIAL == https
> insecure == NONE == http
>
> Am not referring to secured roles triggering different http methods (which
> I like).
>
> Dhanji.
>
> On 9/28/07, Dhanji R. Prasanna <dhanji_at_gmail.com> wrote:
> >
> > 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
> > >
> >
> >
>
--
Ryan J. McDonough
http://www.damnhandy.com