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.
>
>
> 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?
I would say the application should not care. The idea around the
@SecureTransport was that is it will force the caller to use a secure
transport. In the absence of the annotation, the user should have the option
of accessing the resource over either channel.
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.
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>> 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>
> > > For additional commands, e-mail: 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>
> > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
--
Ryan J. McDonough
http://www.damnhandy.com