dev@jsr311.java.net

Re: JAX-RS Security?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 06 Sep 2007 15:15:13 +0200

Hi Ryan,

Nice use-case, i don't know whether this is a corner case or not, but it
would be great if we could get more use-cases like this :-)


Another, potential, way if doing the equivalent in a non-annotated
manner is using a sub-locator method:

class PeopleResource {

     @UriTemplate("{id})
     PersonResource getPerson(@UriParam("id) id) {
         if (role is paid) {
             return PaidPersonResource(id);
         } else {
             return CheapSkatePersonResource(id);
         }
     }
}

or by using @RolesAllowed for sub-locator methods. This approach is
interesting because it enables further sub-resources to be included for
different roles.

Paul.

Ryan McDonough wrote:
> Perhaps what I'm thinking about is a bit of a corner case, but I'm
> thinking in of a situation when you want to potentially control the type
> of representation at a particular URI. For example, supposing the
> Facebook API was a true RESTful application and they offered a free and
> paid plans to the service. In the free scenario, if I call the following
> URI:
>
> http://api.facebook.com/people/12345
>
> I can see basic details about that user like their name and status, but
> I do not see their friends and other details. If i'm a paid service
> member, the representation that is returned would have more detailed
> information about the person and you'd be able to see friends and other
> details.
>
> From a coding perspective, I was thinking it could be something like:
>
> @UriTemplate("/people/{id}")
> @ProduceMime("application/xml")
> public class PersonFinder {
>
> @HttpMethod("GET")
> @RolesAllowed({"basic"})
> public Person getPersonByIdBasic(@UriParam("id") String id) {...
>
> @HttpMethod("GET")
> @RolesAllowed({"paidSubscriber"})
> public Person getPersonByIdFull(@UriParam("id") String id) {...
>
> If the user is in the "paidSubscriber" role, the getPersonByIdFull() is
> executed. Again, maybe this is a corner case, but it's something that
> has come up in a project I have been working on.
>
> Ryan-
>
> On 8/24/07, *Marc Hadley* <Marc.Hadley_at_sun.com
> <mailto:Marc.Hadley_at_sun.com>> wrote:
>
> On Aug 24, 2007, at 11:45 AM, Ryan McDonough wrote:
> >
> > Sorry I'm late to the party but I've been trying to catch up on
> > what has
> > been going on with the development of this specification. One
> item I'm
> > curious about is security in regards to this JSR? Is this an area
> > that has
> > been deemed out of scope for for the JSR, or is something that has
> > not come
> > up in discussions yet?
> >
> We haven't discussed security much beyond noting that its primarily
> something that would typically happen before a request reaches a JSR
> 311 artifact. In an earlier note[1] outlining feedback Paul and I
> received from an internal review I included the following:
>
> > - Consider supporting the standard security annotations defined by
> > JSR 250 and examine JSRs 196 and 115. JSR 196 offers support for
> > pluggable authentication and JSR 115 for authorization. JSR 115 may
> > need a revision to accommodate the more flexible URI patterns
> > supported by @UriTemplate.
>
> So I wouldn't say that security is out-of-scope for this JSR but
> equally I don't think we should be re-inventing any wheels either.
>
> Marc.
>
> [1] https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=549
> <https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=549>
>
> ---
> Marc Hadley <marc.hadley at sun.com <http://sun.com>>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> 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