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.