Hi Paul,
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:
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.
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