Hi Marc,
I can certainly see the point whereby injecting container resources can be a
problem for cases where you may not be using a servlet container. I think
there is still value in being able to inject container specific interface
into resources for the instances where you may want that functionality. In
this case however, I think that adding some principal and role information
to the UriInfo interface maybe a better approach as it will provide some
consistency. So we could have:
class PeopleResource {
@HttpContext UriInfo uriInfo;
@UriTemplate("{id}")
PersonResource getPerson(@UriParam("id) String id) {
if (uriInfo.isUserInRole("paidSubscriber")) {
return PaidPersonResource(id);
} else {
return CheapSkatePersonResource(id);
}
}
}
This at least provides some level of consistency regardless of whether or
not you are running a servlet container. I'm aware that RESTlet does not run
in as a servlet by default and it has a slightly different security
infrastructure as well. I wonder if Jerome has some insight on this thread?
Ryan-
On 9/6/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Sep 6, 2007, at 10:08 AM, Ryan McDonough wrote:
> >
> > I was also considering the sub-locator method as well, but at the
> > moment
> > there doesn't appear to be a means in the API to access security
> > credentials. Perhaps we could do something like:
> >
> If the resource is deployed in a Servlet container then you can
> inject the HttpServletRequest to access the security credentials, e.g.
>
> class PeopleResource {
>
> @Resource HttpServletRequest ctx;
>
> @UriTemplate("{id}")
> PersonResource getPerson(@UriParam("id) String id) {
> if (ctx.isUserInRole("paidSubscriber")) {
> return PaidPersonResource(id);
> } else {
> return CheapSkatePersonResource(id);
> }
> }
> }
>
>
> > class PeopleResource {
> >
> > @UriTemplate("{id})
> > PersonResource getPerson(@UriParam("id) String id, @HttpContext
> > SecurityContext ctx) {
> > if (ctx.isUserInRole("paidSubscriber")) {
> > return PaidPersonResource(id);
> > } else {
> > return CheapSkatePersonResource(id);
> > }
> > }
> > }
> >
> > I'm thinking that "SecurityContext" (please chime in with a more
> > appropriate
> > name) would be injected just as any other HTTP Context element and
> > could
> > provide some similar functionality as an EJBContext, but limited to
> > just the
> > role and principal details.
> >
> There's a tension between relying on injection of container-specific
> interfaces (like HttpServletRequest as I suggest above) and defining
> new interfaces that duplicate methods in container-specific
> interfaces but then offer a common API for JAX-RS application on any
> container. I think that our current UriInfo and HttpHeaders
> interfaces offer sufficient useful additional capabilities over the
> Servlet equivalent to justify their existence but for security
> information I don't think we're there yet. Perhaps if we can come up
> with something to address your usecase below we could consider
> rolling the common methods into that ?
>
> Marc.
>
> > I actually do have a few other thoughts that I'm trying to work out
> > which
> > are in a similar context. I don't really have a solution yet, and
> > it may
> > even be beyond the scope of the JSR. With the growing number of
> > "Web APIs",
> > there's some new authorization challenges. Again, using the
> > Facebook API as
> > an example, you can almost have two levels of authentication:
> >
> > - The API user who is providing the service
> > - The local user who is using a Facebook application
> >
> > The API user needs a key which they must pass in every request.
> > Additionally, the Facebook user must authenticate using the
> > Facebook web
> > site which authenticates yet another token which used at the
> > individual user
> > level. Personally, I think the way Facebook has implemented their
> > authorization process promotes a lousy user experience. If you're
> > developing
> > a desktop application that uses the Facebook API, the user has to
> > leave the
> > application and login via a web browser and once authenticated,
> > return to
> > the desktop application.
> >
> > Now with all of that said, I'm trying to think about the following:
> >
> > - Is there a way we can handle the concept of an API key in the API
> > without being too over bearing?
> > - In addition to the API key, is there a way to manage user
> > authentication against an API key?
> > - Is this all too involved for the API?
> >
> > Personally, I think if we can address some of these items, it could
> > make it
> > more attractive for developers to create Web APIs in Java rather
> > than PHP or
> > Ruby. Thoughts?
> >
> > Ryan-
> >
> > On 9/6/07, Paul Sandoz < Paul.Sandoz_at_sun.com> wrote:
> >>
> >> 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
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> 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