Ryan McDonough wrote:
> Do you think there will be use-cases where NONE, INTEGRAL (whatever that
> is!), and CONFIDENTIAL transports will be used in the same application?
> If this is the case then methods and annotations would be required but
> if not does the application really need to know?
>
>
> Honestly, I don't see the need for three variants to specify the type of
> transport. I'm probably missing something, but I feel that the transport
> should either fully secure or not, nothing in between. I can see your
> point that the annotation maybe pointless from the applications
> perspective. But I can see a can where maybe you would mix it up. Using
> the same example as before, if the representation for the paid
> subscriber contains confidential information, maybe you want to the
> force the caller to use SSL. Otherwise, maybe you don't care. I guess
> the big thing here is that the annotation enforces the use of SSL, where
> in the absense of, SSL would be optional.
>
I see. Just wondering if it is sufficient to tie such rules to a role
instead of at the application level. For example, in the case of
@RolesAllowed({"paidSubscriber"}) the runtime can check if the role
"paidSubscriber" requires SSL or not. The trouble is i ain't a security
expert so don't know what the right approaches are.
On another point it can make testing trickier, when using HTTP proxies
to log requests and responses, and for such cases the runtime needs a
"testing mode" to fool the application into thinking the transport is
secure when it is not.
Paul.
> As you can guess wondering whether we need such transport-level methods
> and annotations and we can instead trigger things by application
> defaults associated with the RolesAllowed e.g. a user in this role
> requires a secure transport.
>
> Paul.
>
> Ryan McDonough wrote:
> > Hi Paul,
> >
> > Yeah, I i was writing this on the train into work and forgot to
> add that
> > element. An additional annotation could be added to force a secure
> > transport:
> >
> >
> > class PeopleResource {
> >
> > @UriTemplate("{id}")
> > @RolesAllowed({"paidSubscriber"})
> > @SecureTransport
> > PersonResource getPaidPersonResource (@UriParam("id) String id) {
> > return PaidPersonResource(id);
> > }
> >
> > @UriTemplate("{id}")
> > @RolesAllowed({"basic"})
> > PersonResource getCheapSkatePersonResource( UriParam("id)
> String id) {
> > return CheapSkatePersonResource (id);
> > }
> > }
> >
> > This would force a check to to see if the transport is secure. If
> the
> > transport is not secure, the caller is redirected to the same URI but
> > using a secure channel. This is the Java EE behavior when using the
> > <user-data-constraint> with a <transport-guarantee> element with
> a value
> > of either NONE,INTEGRAL, or CONFIDENTIAL. I never fully full
> grasped the
> > difference between INTEGRAL vs. CONFIDENTIAL as I have always
> used the
> > latter.
> >
> > I am aware that this is slightly redundant with the web.xml
> definitions,
> > but it does enable some more flexibility in that a basic use doesn't
> > have to use SSL, but since a paid user could have access to more
> > sensitive information, you could force them to use a secure
> channel. You
> > can't do this with a web app today.
> >
> > As far as the annotation goes, @SecureChannel would for this check if
> > present. It can be a class or method level annotation. If we
> wanted more
> > flexibility like the web.xml, it we could optionally do something
> like:
> >
> > class PeopleResource {
> >
> > @UriTemplate("{id}")
> > @RolesAllowed({"paidSubscriber"})
> > @TransportGuarantee( TransportType.CONFIDENTIAL)
> > PersonResource getPaidPersonResource (@UriParam("id) String id) {
> > return PaidPersonResource(id);
> > }
> >
> > @UriTemplate("{id}")
> > @RolesAllowed({"basic"})
> > @TransportGuarantee(TransportType.NONE)
> > PersonResource getCheapSkatePersonResource( UriParam("id)
> String id) {
> > return CheapSkatePersonResource (id);
> > }
> > }
> >
> > This would make it more consistent with the web.xml.
> >
> > Ryan-
> >
> > On 9/21/07, *Paul Sandoz* < Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>
> > <mailto: Paul.Sandoz_at_sun.com <mailto:Paul.Sandoz_at_sun.com>>> wrote:
> >
> > Hi Ryan,
> >
> > This looks good.
> >
> > I notice there is no annotation equivalent for checking if the
> > transport
> > is secure. In EE today do app servers redirect from an
> insecure URI to a
> > secure URI at a low level before reaching the servlet container?
> >
> > Paul.
> >
> > Ryan McDonough wrote:
> > > All,
> > >
> > > Attached is an idea for an injectable SecurityContext
> interface that
> > > would provide access to security related information.
> Usage of this
> > > interface would be as follows:
> > >
> > > class PeopleResource {
> > >
> > > @HttpContext SecurityContext securityContext;
> > >
> > > @UriTemplate("{id}")
> > > PersonResource getPerson(@UriParam("id) String id) {
> > > if (securityContext.isUserInRole("paidSubscriber")) {
> > > return PaidPersonResource(id);
> > > } else {
> > > return CheapSkatePersonResource(id);
> > > }
> > > }
> > > }
> > >
> > > Additionally, you could test that the PaidPersonResource
> is being
> > > requested over a secure channel:
> > >
> > > class PeopleResource {
> > >
> > > @HttpContext SecurityContext securityContext;
> > >
> > > @UriTemplate("{id}")
> > > PersonResource getPerson(@UriParam("id) String id) {
> > > if ( securityContext.isUserInRole("paidSubscriber")) {
> > > if(securityContext.isTransportSecure()) {
> > > return PaidPersonResource(id);
> > > }else {
> > > //-- Return Error
> > > }
> > >
> > > } else {
> > > return CheapSkatePersonResource(id);
> > > }
> > > }
> > > }
> > >
> > > Optionally, we could use JSR-250 annotation to perform the
> same task
> > > declaratively:
> > >
> > >
> > > class PeopleResource {
> > >
> > > @UriTemplate("{id}")
> > > @RolesAllowed({"paidSubscriber"})
> > > PersonResource getPaidPersonResource (@UriParam("id)
> String id) {
> > > return PaidPersonResource(id);
> > > }
> > >
> > > @UriTemplate("{id}")
> > > @RolesAllowed({"basic"})
> > > PersonResource getCheapSkatePersonResource( UriParam("id)
> > String id) {
> > > return CheapSkatePersonResource (id);
> > > }
> > > }
> > >
> > > As far as configuring a security domain, this is probably
> > something best
> > > left to the container, but I haven't worked out the exact
> details
> > yet.
> > >
> > > Ryan-
> > > --
> > > Ryan J. McDonough
> > > http://www.damnhandy.com
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
>
> >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> > <mailto:dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>>
> > > For additional commands, e-mail:
> dev-help_at_jsr311.dev.java.net <mailto:dev-help_at_jsr311.dev.java.net>
> > <mailto:dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>>
> >
> > --
> > | ? + ? = To question
> > ----------------\
> > Paul Sandoz
> > x38109
> > +33-4-76188109
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> > <mailto:dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>>
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
> > <mailto:dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>>
> >
> >
> >
> >
> > --
> > Ryan J. McDonough
> > http://www.damnhandy.com
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
>
>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109