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> 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
> > For additional commands, e-mail: 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
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
--
Ryan J. McDonough
http://www.damnhandy.com