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
> >
>
>