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