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.