You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Dirk Balfanz <di...@gmail.com> on 2008/07/01 06:58:11 UTC
Re: OAuth support in RESTful server
Brian left a detailed list of comments on the latest patch for this:
https://issues.apache.org/jira/browse/SHINDIG-290
Apart from some simple renaming/refactoring suggestions, Brian put his
finger on two issues that we couldn't figure out ourselves when we talked
about it today, so I wanted to bring them up here:
(1) Why do we use (two-legged) OAuth when there is a security token in the
request? The security token itself is a signed statement of user identities,
so what's the purpose of stacking OAuth on top of it?
(2) With the different ways of establishing the identity of the principal
making the request, how exactly do we resolve the case when there are
clashes? Right now in the code, I prioritize OAuth token over gadget
security token over xoauth_requestor_id. (i.e. only if there is no OAuth
token in the request do I even look if there is a gadget security token,
etc.). That's a pretty arbitrary decision, and uses the presence/absence of
paramters in the request as "hints" as to what authentication was desired.
What if someone happens to include a URL query param named "st" in the
request that is not, actually, a gadget security token? Should I signal an
error because the "security token" didn't parse? Should I see whether
instead there is an xoauth_requestor_id parameter present? Wouldn't it be
cleaner if the request someone carried an explicit signal with it that told
the REST server what kind of authentication is being used?
Please ponder these questions while I refactor some of the code :-) I'm
curious to see what people think...
Dirk.
On Thu, Jun 19, 2008 at 9:31 PM, John Panzer <jp...@google.com> wrote:
> Sounds good. One additional case is where there is a two legged call
> with no xoauth_requestor_id, meaning 'do this on behalf of the
> Consumer alone, without a particular user making the request'.
>
> On 6/19/08, Dirk Balfanz <di...@gmail.com> wrote:
> > I just had a conversation with John Panzer and David Primmer, and it
> cleared
> > up some of my misconceptions. I had assumed that the RESTful server would
> > have to make access control decisions based on the viewer and owner of
> > gadgets, and I just couldn't square that with the notion of user accounts
> on
> > that server (i.e. individual users authenticating to the server not as
> > "viewer" or "owner", but just as a user).
> >
> > Anyway, it turns out that the RESTful server, in fact, doesn't have a
> notion
> > of viewer or owner at all - it only has a notion of the "user making the
> > request" to the server. So, in light of that, the plan for implementation
> is
> > as follows:
> >
> >
> > - The goal of the oauth servlet filter is to authenticate the user
> making
> > the request [1]. This will be done in a variety of ways:
> >
> >
> > 1. if the incoming request is from the container's own gadget server,
> the
> > request will be signed using "two-legged" OAuth (aka signedFetch),
> and
> > include a gadget security token. The gadget security token includes
> > the
> > owner and the viewer, expressed in identities native to the
> > container. The
> > principal that will be represented to the servlets as "making
> > the request"
> > is the viewer. (If a gadget doesn't like that, it can make a raw
> > OAuth call
> > to the RESTful API server and use the token of the page owner,
> which
> > will
> > then be used according to point (2) below).
> >
> > 2. if the incoming request is from a third-party-server that uses
> > "full" (as opposed to "two-legged") OAuth, then the request will
> > include an
> > OAuth token that identifies the user. We'll have an interface that
> > will
> > allow containers to map OAuth tokens to their native identities.
> The
> > principal that will be represented to the servlets as "making
> > the request"
> > is the principal the OAuth token maps to.
> >
> > 3. if the incoming request is from a third-party-server that uses
> > "two-legged" OAuth (aka signedFetch), it won't include a gadget
> > security
> > token. Instead, it must include a xoauth_requestor_id parameter,
> > which names
> > the requester principal in a format native to the container.
> > The principal
> > that will be represented to the servlets as "making the request" is
> > the
> > principal identified in the xoauth_requestor_id.
> >
> >
> >
> > - The principal making the request will be communicated to the
> servlets
> > through the getUserPrincipal() method in the HttpServletResponse.
> > getAuthType() will return "OAuth" in each case.
> >
> >
> > What should we do if the incoming request doesn't fall into one of the
> three
> > categories, or if the signatures don't check out etc? Should the filter
> let
> > the request through to the gadget and just not label them as
> authenticated,
> > or should the filter return a 401?
> >
> > Dirk.
> >
> >
> > [1] Note that we're not talking about authorization yet (i.e. rules of
> who
> > can access what) - this is just authentication, i.e. figuring out who the
> > "who" is.
> >
> > On Wed, Jun 18, 2008 at 10:55 PM, Kevin Brown <et...@google.com> wrote:
> >> On Wed, Jun 18, 2008 at 9:14 PM, Dirk Balfanz <di...@gmail.com>
> >> wrote:
> >>
> >>> > A RESTful client is a proxy for a user. Getting the activities for a
> >>> given
> >>> > user doesn't make any sense without ACLs, and you can't have ACLs
> > without
> >>> > authenticating a user.
> >>>
> >>> Sure you can. You authenticate the proxy (not the user), and just let
> >>> the proxy tell you whose user's data they want to access. No need for
> >>> individual users to have accounts. What am I missing here?
> >>
> >>
> >> Well, you'd still have to grant permission for a client to access a
> >> particular user's data. There are two ways to do this:
> >>
> >> - Whitelist the client for all users, require the client to pass user
> >> credentials per request.
> >> - Whitelist the client for individual users at "install" time, no
> >> per-request user credentials required.
> >>
> >> The second case is probably simpler for the case of simple relationships
> >> (@self), but is more complicated to implement queries for friends. In
> > either
> >> case, you still have accounts, you just shift the burden of doing the
> > oauth
> >> flow from the client to the provider.
> >>
> >>
> >>>
> >>> Dirk.
> >>>
> >>>
> >>> >
> >>> >
> >>> >>
> >>> >> Dirk.
> >>> >>
> >>> >> On Wed, Jun 18, 2008 at 5:52 PM, Chris Chabot <ch...@xs4all.nl>
> >>> wrote:
> >>> >> > The practice so far has been to implement the proper code, define
> >>> >> interfaces
> >>> >> > for your data call (a authenticate(user, password) type thing in
> > this
> >>> >> case),
> >>> >> > and then make a sample implementation using the
> >>> >> > shindig/javascript/samplecontainer/state-basicfriendlist.xml file.
> >>> >> >
> >>> >> > You could just add some user info entries to that xml file, and
> then
> >>> make
> >>> >> a
> >>> >> > SampleAuthorisationService.java (that impliments the
> >>> AuthorisationService
> >>> >> > interface) or something like that, which uses the xml file's data
> > for
> >>> the
> >>> >> > authentication.
> >>> >> >
> >>> >> > Since your in multi threaded java, you can just keep the
> > authenticated
> >>> >> > sessions in memory, no worries that their destroyed on a restart,
> > it's
> >>> >> just
> >>> >> > a demo anyhow.
> >>> >> >
> >>> >> > Real containers would then replace the config from
> >>> >> > SampleAuthorisationService (again that's just an example, not a
> real
> >>> file
> >>> >> > name suggestion) to MyOwnAuthorisationService, and put their real
> >>> >> > authorization code in that.
> >>> >> >
> >>> >> > Take a look at the current
> >>> org.apache.shindig.opensocial.samplecontainer
> >>> >> > files to get a feel for how that works for the other
> > interface/sample
> >>> >> stuff
> >>> >> >
> >>> >> > -- Chris
> >>> >> >
> >>> >> > On Jun 19, 2008, at 2:36 AM, Dirk Balfanz wrote:
> >>> >> >
> >>> >> >> Hi guys,
> >>> >> >>
> >>> >> >> Cassie and David asked me to summarize where we're at with OAuth
> >>> >> >> support in the RESTful server. I volunteered to help out, but
> have
> > to
> >>> >> >> admit that I don't have the full picture yet.
> >>> >> >>
> >>> >> >> Here is what I know how to do: I can write a ServletFilter that
> can
> >>> >> >> verify incoming signedFetch requests against a list of known
> public
> >>> >> >> keys (known to the RESTful server, that is), and then assert the
> >>> >> >> originator of that request (the string passed in
> > oauth_consumer_key)
> >>> >> >> to the filters and servlets downstream.
> >>> >> >>
> >>> >> >> For anything else (like "real" incoming OAuth requests) the
> RESTful
> >>> >> >> server would have to have some sort of notion of user accounts,
> > which
> >>> >> >> AFAIK is not the case. I'm saying that because normally, when an
> >>> OAuth
> >>> >> >> request comes in, you verify the request, and then you map the
> >>> >> >> supplied OAuth token to an account on your server.
> >>> >> >>
> >>> >> >> So I'm not quite sure what it means to "support OAuth" for the
> >>> RESTful
> >>> >> >> server (minus the signedFetch part, as explained above), but I'm
> >>> >> >> willing to help implement it if someone can explain it to me. :-)
> >>> >> >>
> >>> >> >> Any takers?
> >>> >> >>
> >>> >> >> Dirk.
> >>> >> >
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >
>
Re: OAuth support in RESTful server
Posted by Brian Eaton <be...@google.com>.
On Tue, Jul 1, 2008 at 3:33 PM, Dirk Balfanz <di...@gmail.com> wrote:
> I disagree. The principal represented by the consumer has even less to do
> with the principal making the request than the original delegater.
Presumably the service provider has a database that records that user
U delegated access to consumer C. In that case, knowing who the
consumer is will be sufficient to know what access rights they have.
Or maybe not. Maybe the SP will need to see the access token to figure
that out. Both modes are reasonable, so we should support both.
> you mean getUserPrincipal().getName(), right?
>>
>> getAuthType
>
>
> this would be HttpServletRequest, right?
Probably. =)
>> getOwner, getViewer, getGadget
>> getOAuthMessage().get("oauth_consumer")
>> getOAuthMessage().get("oauth_token")
>> etc...
>>
>
> I was more leaning toward something like having a method checkAccess(String
> httpMethod, String pathFromUrl) on that principal object, but mostly I would
> suggest crossing the authorization bridge when we get there. For now, let's
> just worry about authentication.
Sounds fine. Just so long as the Principal object has references to
all of the various bits of stuff that came out of the authentication
process (e.g. an authenticated OAuthMessage or GadgetSecurityToken),
we should be fine.
Re: OAuth support in RESTful server
Posted by Dirk Balfanz <di...@gmail.com>.
>
> This won't work for several of the use cases discussed in this thread,
> e.g. access to a user's contacts, but not their other data, or
> read-only access to contacts.
>
You're right, I think I said that wrong. The principal "making the request"
is related to the one the OAuth token maps to (below called the delegater),
in that it may possess only a subset of the privileges of the delegater.
> A more useful mapping would be from oauth token to OAuth consumer
> identity, since the OAuth consumer is the one making the request. The
> question shouldn't be "Does user X have permission to modify user X's
> contacts", it should be "Does consumer K have permission to modify
> user X's contacts"
>
I disagree. The principal represented by the consumer has even less to do
with the principal making the request than the original delegater. Consumer
K never has permission to modify anything. If it did, user's wouldn't have
to give it OAuth tokens. I like your suggestion below better (where the
principal's getName() method shows both consumer and token (and perhaps
delegater, I guess), but where the getName() method is one of the less
useful methods on the principal).
getUserPrincipal should probably return some ornate string that no one
> will actually use for anything. This is too complicated to fit into a
>
you mean getUserPrincipal().getName(), right?
> The actual authorization should be based on calls on the principal object
> like:
>
> getAuthType
this would be HttpServletRequest, right?
> getOwner, getViewer, getGadget
> getOAuthMessage().get("oauth_consumer")
> getOAuthMessage().get("oauth_token")
> etc...
>
I was more leaning toward something like having a method checkAccess(String
httpMethod, String pathFromUrl) on that principal object, but mostly I would
suggest crossing the authorization bridge when we get there. For now, let's
just worry about authentication.
Dirk.
Re: OAuth support in RESTful server
Posted by Brian Eaton <be...@google.com>.
On Mon, Jun 30, 2008 at 11:44 PM, Dirk Balfanz <di...@gmail.com> wrote:
> Ok, Take 2, then, on the proposal. How about this: There are two filters for
> authentication. First is an OAuth filter, second is a gadget-security-token
> (GST) filter.
Why should there be two filters? You're already verifying the GST in
the OAuth filter, seems like it is just a matter of moving that code a
bit.
Either way, both filters should provide the same Principal
subinterface for use by the authorization code.
>
> - The OAuth filter does the following:
>
>
> 1. if the incoming request is from a third-party-server that uses "full"
> (as opposed to "two-legged") OAuth, then the request will
> include an OAuth
> token that identifies the user. We'll have an interface that will allow
> containers to map OAuth tokens to their native identities. The principal
> that will be represented to the servlets as "making the request" is the
> principal the OAuth token maps to.
This won't work for several of the use cases discussed in this thread,
e.g. access to a user's contacts, but not their other data, or
read-only access to contacts.
A more useful mapping would be from oauth token to OAuth consumer
identity, since the OAuth consumer is the one making the request. The
question shouldn't be "Does user X have permission to modify user X's
contacts", it should be "Does consumer K have permission to modify
user X's contacts"
My take? Provide the entire OAuth message in the DelegatedPrincipal
object, perhaps with some convenience methods to get the OAuth
consumer key and OAuth access token. That way the authorization code
has plenty of flexibility in the businss logic. Put another way: the
OAuth filter proves the message is authentic, and other code is
responsible for deciding what that message should accomplish.
>
> 2. if the incoming request is from a third-party-server that uses
> "two-legged" OAuth (aka signedFetch), it won't include an OAuth token.
> Instead, it must include a xoauth_requestor_id parameter, which names the
> requester principal in a format native to the container. The
> principal that
> will be represented to the servlets as "making the request" is
> the principal
> identified in the xoauth_requestor_id.
Same problem as above, permissions are a subset based on the OAuth
consumer key and the OAuth requestor id. The same solution as above
should work.
But you'll want to distinguish between the two cases: it is quite
possible that two-legged OAuth will need different authorization rules
than full OAuth.
> The principal making the request will be communicated to the servlets
> through the getUserPrincipal() method in the HttpServletResponse.
> getAuthType() will return "OAuth" in each case.
getAuthType should distinguish between gadget security token, full
OAuth, and two legged OAuth.
getUserPrincipal should probably return some ornate string that no one
will actually use for anything. This is too complicated to fit into a
single user identity, so we should discourage people from using
getUserPrincipal for anything except debugging. How about a principal
name like "oauth_consumer_key=<consumer>&oauth_token=<token>"
The actual authorization should be based on calls on the principal object like:
getAuthType
getOwner, getViewer, getGadget
getOAuthMessage().get("oauth_consumer")
getOAuthMessage().get("oauth_token")
etc...
(I know that this is annoying, but it is also the only way to
implement the business logic.)
Re: OAuth support in RESTful server
Posted by Dirk Balfanz <di...@gmail.com>.
On Tue, Jul 1, 2008 at 2:06 PM, John Panzer <jp...@google.com> wrote:
>
>
> Yes; the security token is an alternative to OAuth, and is currently only
> usable by the OpenSocial JS API. Is that different from what was discussed
> previously?
Yeah, the previous version you greenlighted had an OAuth signature on
requests with gadget security tokens.
Oh well :-)
Dirk.
Re: OAuth support in RESTful server
Posted by John Panzer <jp...@google.com>.
John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 11:44 PM, Dirk Balfanz <di...@gmail.com>
wrote:
> > You'd use two legged OAuth in case a third party client (not the JS API
> > that
> > has a security token) wants to talk to you. They don't have a security
> > token because you they aren't your site, but they do have enough trust
> (via
> > out of band registration or other agreements) to let you let them make
> two
> > legged calls to you.
> >
>
> So you're now saying that if you use a gadget security token then there is
> no OAuth involved - not the normal OAuth (with an oauth_token), and not the
> two-legged OAuth (with just a consumer_key)?
Yes; the security token is an alternative to OAuth, and is currently only
usable by the OpenSocial JS API. Is that different from what was discussed
previously?
>
>
>
> > So perhaps: Prioritize OAuth first (in URL parameters and Authorization:
> > header of course), if there are any oauth params then ignore st. Else,
> > look
> > for st and use that if possible. Else, error.
>
>
> Ok, Take 2, then, on the proposal. How about this: There are two filters
> for
> authentication. First is an OAuth filter, second is a gadget-security-token
> (GST) filter.
>
> - The OAuth filter does the following:
>
>
> 1. if the incoming request is from a third-party-server that uses "full"
> (as opposed to "two-legged") OAuth, then the request will
> include an OAuth
> token that identifies the user. We'll have an interface that will
> allow
> containers to map OAuth tokens to their native identities. The
> principal
> that will be represented to the servlets as "making the request" is
> the
> principal the OAuth token maps to.
>
> 2. if the incoming request is from a third-party-server that uses
> "two-legged" OAuth (aka signedFetch), it won't include an OAuth
> token.
> Instead, it must include a xoauth_requestor_id parameter, which names
> the
> requester principal in a format native to the container. The
> principal that
> will be represented to the servlets as "making the request" is
> the principal
> identified in the xoauth_requestor_id.
>
Check, except that sometimes there is no xoauth_requestor_id and therefore
no (user) principal. MySpace has this use case for example. I _think_
this just means that getUserPrincipal() should return null, Shindig code
should be prepared to handle null, and containers that want to support this
need to be prepared to handle null==getUserPrincipal().
>
>
> The principal making the request will be communicated to the servlets
> through the getUserPrincipal() method in the HttpServletResponse.
> getAuthType() will return "OAuth" in each case.
>
Great.
>
>
>
> - The GST filter then does the following:
> 1. If the HttpServletRequest says that the request has already been
> authenticated (getAuthType() != null) then it does nothing.
> 2. Else, if the incoming request is from the container's own gadget
> server, the request will include a gadget security token. The gadget
> security token includes the owner and the viewer, expressed in
> identities
> native to the container. The GST filter validates the GST. The
> principal
> that will be represented to the servlets as "making the request" is
> the
> viewer. (If a gadget doesn't like that, it can make a raw OAuth
> call to the
> RESTful API server and use the token of the page owner, which
> will then be
> used according to point (1) in the OAuth filter explanation).
>
> The principal making the request will be communicated to the servlets
> through the getUserPrincipal() method in the HttpServletResponse.
> getAuthType() will return "GadgetSecurityToken" in this case.
>
> How's that?
>
LGTM
>
> Dirk.
>
Re: OAuth support in RESTful server
Posted by Dirk Balfanz <di...@gmail.com>.
> You'd use two legged OAuth in case a third party client (not the JS API
> that
> has a security token) wants to talk to you. They don't have a security
> token because you they aren't your site, but they do have enough trust (via
> out of band registration or other agreements) to let you let them make two
> legged calls to you.
>
So you're now saying that if you use a gadget security token then there is
no OAuth involved - not the normal OAuth (with an oauth_token), and not the
two-legged OAuth (with just a consumer_key)?
> So perhaps: Prioritize OAuth first (in URL parameters and Authorization:
> header of course), if there are any oauth params then ignore st. Else,
> look
> for st and use that if possible. Else, error.
Ok, Take 2, then, on the proposal. How about this: There are two filters for
authentication. First is an OAuth filter, second is a gadget-security-token
(GST) filter.
- The OAuth filter does the following:
1. if the incoming request is from a third-party-server that uses "full"
(as opposed to "two-legged") OAuth, then the request will
include an OAuth
token that identifies the user. We'll have an interface that will allow
containers to map OAuth tokens to their native identities. The principal
that will be represented to the servlets as "making the request" is the
principal the OAuth token maps to.
2. if the incoming request is from a third-party-server that uses
"two-legged" OAuth (aka signedFetch), it won't include an OAuth token.
Instead, it must include a xoauth_requestor_id parameter, which names the
requester principal in a format native to the container. The
principal that
will be represented to the servlets as "making the request" is
the principal
identified in the xoauth_requestor_id.
The principal making the request will be communicated to the servlets
through the getUserPrincipal() method in the HttpServletResponse.
getAuthType() will return "OAuth" in each case.
- The GST filter then does the following:
1. If the HttpServletRequest says that the request has already been
authenticated (getAuthType() != null) then it does nothing.
2. Else, if the incoming request is from the container's own gadget
server, the request will include a gadget security token. The gadget
security token includes the owner and the viewer, expressed in identities
native to the container. The GST filter validates the GST. The principal
that will be represented to the servlets as "making the request" is the
viewer. (If a gadget doesn't like that, it can make a raw OAuth
call to the
RESTful API server and use the token of the page owner, which
will then be
used according to point (1) in the OAuth filter explanation).
The principal making the request will be communicated to the servlets
through the getUserPrincipal() method in the HttpServletResponse.
getAuthType() will return "GadgetSecurityToken" in this case.
How's that?
Dirk.
Re: OAuth support in RESTful server
Posted by John Panzer <jp...@google.com>.
John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 9:58 PM, Dirk Balfanz <di...@gmail.com>
wrote:
> Brian left a detailed list of comments on the latest patch for this:
> https://issues.apache.org/jira/browse/SHINDIG-290
>
> Apart from some simple renaming/refactoring suggestions, Brian put his
> finger on two issues that we couldn't figure out ourselves when we talked
> about it today, so I wanted to bring them up here:
>
> (1) Why do we use (two-legged) OAuth when there is a security token in the
> request? The security token itself is a signed statement of user
> identities,
> so what's the purpose of stacking OAuth on top of it?
You'd use two legged OAuth in case a third party client (not the JS API that
has a security token) wants to talk to you. They don't have a security
token because you they aren't your site, but they do have enough trust (via
out of band registration or other agreements) to let you let them make two
legged calls to you.
>
>
> (2) With the different ways of establishing the identity of the principal
> making the request, how exactly do we resolve the case when there are
> clashes? Right now in the code, I prioritize OAuth token over gadget
> security token over xoauth_requestor_id. (i.e. only if there is no OAuth
> token in the request do I even look if there is a gadget security token,
> etc.). That's a pretty arbitrary decision, and uses the presence/absence of
> paramters in the request as "hints" as to what authentication was desired.
> What if someone happens to include a URL query param named "st" in the
> request that is not, actually, a gadget security token? Should I signal an
> error because the "security token" didn't parse? Should I see whether
> instead there is an xoauth_requestor_id parameter present? Wouldn't it be
> cleaner if the request someone carried an explicit signal with it that told
> the REST server what kind of authentication is being used?
>
You should never see both security token and OAuth together. I'd prioritize
gadget security token first, except that it has the unfortunate property of
hogging the "st" parameter namespace. (IMHO it'd be better if the security
token weren't in the URL but in a header somewhere -- less spoofable,
clearer, just as easy to create on the client side, but I think that ship
has sailed.)
So perhaps: Prioritize OAuth first (in URL parameters and Authorization:
header of course), if there are any oauth params then ignore st. Else, look
for st and use that if possible. Else, error.
>
> Please ponder these questions while I refactor some of the code :-) I'm
> curious to see what people think...
>
> Dirk.
>
>
> On Thu, Jun 19, 2008 at 9:31 PM, John Panzer <jp...@google.com> wrote:
>
> > Sounds good. One additional case is where there is a two legged call
> > with no xoauth_requestor_id, meaning 'do this on behalf of the
> > Consumer alone, without a particular user making the request'.
> >
> > On 6/19/08, Dirk Balfanz <di...@gmail.com> wrote:
> > > I just had a conversation with John Panzer and David Primmer, and it
> > cleared
> > > up some of my misconceptions. I had assumed that the RESTful server
> would
> > > have to make access control decisions based on the viewer and owner of
> > > gadgets, and I just couldn't square that with the notion of user
> accounts
> > on
> > > that server (i.e. individual users authenticating to the server not as
> > > "viewer" or "owner", but just as a user).
> > >
> > > Anyway, it turns out that the RESTful server, in fact, doesn't have a
> > notion
> > > of viewer or owner at all - it only has a notion of the "user making
> the
> > > request" to the server. So, in light of that, the plan for
> implementation
> > is
> > > as follows:
> > >
> > >
> > > - The goal of the oauth servlet filter is to authenticate the user
> > making
> > > the request [1]. This will be done in a variety of ways:
> > >
> > >
> > > 1. if the incoming request is from the container's own gadget
> server,
> > the
> > > request will be signed using "two-legged" OAuth (aka
> signedFetch),
> > and
> > > include a gadget security token. The gadget security token
> includes
> > > the
> > > owner and the viewer, expressed in identities native to the
> > > container. The
> > > principal that will be represented to the servlets as "making
> > > the request"
> > > is the viewer. (If a gadget doesn't like that, it can make a raw
> > > OAuth call
> > > to the RESTful API server and use the token of the page owner,
> > which
> > > will
> > > then be used according to point (2) below).
> > >
> > > 2. if the incoming request is from a third-party-server that uses
> > > "full" (as opposed to "two-legged") OAuth, then the request will
> > > include an
> > > OAuth token that identifies the user. We'll have an interface
> that
> > > will
> > > allow containers to map OAuth tokens to their native identities.
> > The
> > > principal that will be represented to the servlets as "making
> > > the request"
> > > is the principal the OAuth token maps to.
> > >
> > > 3. if the incoming request is from a third-party-server that uses
> > > "two-legged" OAuth (aka signedFetch), it won't include a gadget
> > > security
> > > token. Instead, it must include a xoauth_requestor_id parameter,
> > > which names
> > > the requester principal in a format native to the container.
> > > The principal
> > > that will be represented to the servlets as "making the request"
> is
> > > the
> > > principal identified in the xoauth_requestor_id.
> > >
> > >
> > >
> > > - The principal making the request will be communicated to the
> > servlets
> > > through the getUserPrincipal() method in the HttpServletResponse.
> > > getAuthType() will return "OAuth" in each case.
> > >
> > >
> > > What should we do if the incoming request doesn't fall into one of the
> > three
> > > categories, or if the signatures don't check out etc? Should the filter
> > let
> > > the request through to the gadget and just not label them as
> > authenticated,
> > > or should the filter return a 401?
> > >
> > > Dirk.
> > >
> > >
> > > [1] Note that we're not talking about authorization yet (i.e. rules of
> > who
> > > can access what) - this is just authentication, i.e. figuring out who
> the
> > > "who" is.
> > >
> > > On Wed, Jun 18, 2008 at 10:55 PM, Kevin Brown <et...@google.com> wrote:
> > >> On Wed, Jun 18, 2008 at 9:14 PM, Dirk Balfanz <dirk.balfanz@gmail.com
> >
> > >> wrote:
> > >>
> > >>> > A RESTful client is a proxy for a user. Getting the activities for
> a
> > >>> given
> > >>> > user doesn't make any sense without ACLs, and you can't have ACLs
> > > without
> > >>> > authenticating a user.
> > >>>
> > >>> Sure you can. You authenticate the proxy (not the user), and just let
> > >>> the proxy tell you whose user's data they want to access. No need for
> > >>> individual users to have accounts. What am I missing here?
> > >>
> > >>
> > >> Well, you'd still have to grant permission for a client to access a
> > >> particular user's data. There are two ways to do this:
> > >>
> > >> - Whitelist the client for all users, require the client to pass user
> > >> credentials per request.
> > >> - Whitelist the client for individual users at "install" time, no
> > >> per-request user credentials required.
> > >>
> > >> The second case is probably simpler for the case of simple
> relationships
> > >> (@self), but is more complicated to implement queries for friends. In
> > > either
> > >> case, you still have accounts, you just shift the burden of doing the
> > > oauth
> > >> flow from the client to the provider.
> > >>
> > >>
> > >>>
> > >>> Dirk.
> > >>>
> > >>>
> > >>> >
> > >>> >
> > >>> >>
> > >>> >> Dirk.
> > >>> >>
> > >>> >> On Wed, Jun 18, 2008 at 5:52 PM, Chris Chabot <ch...@xs4all.nl>
> > >>> wrote:
> > >>> >> > The practice so far has been to implement the proper code,
> define
> > >>> >> interfaces
> > >>> >> > for your data call (a authenticate(user, password) type thing in
> > > this
> > >>> >> case),
> > >>> >> > and then make a sample implementation using the
> > >>> >> > shindig/javascript/samplecontainer/state-basicfriendlist.xml
> file.
> > >>> >> >
> > >>> >> > You could just add some user info entries to that xml file, and
> > then
> > >>> make
> > >>> >> a
> > >>> >> > SampleAuthorisationService.java (that impliments the
> > >>> AuthorisationService
> > >>> >> > interface) or something like that, which uses the xml file's
> data
> > > for
> > >>> the
> > >>> >> > authentication.
> > >>> >> >
> > >>> >> > Since your in multi threaded java, you can just keep the
> > > authenticated
> > >>> >> > sessions in memory, no worries that their destroyed on a
> restart,
> > > it's
> > >>> >> just
> > >>> >> > a demo anyhow.
> > >>> >> >
> > >>> >> > Real containers would then replace the config from
> > >>> >> > SampleAuthorisationService (again that's just an example, not a
> > real
> > >>> file
> > >>> >> > name suggestion) to MyOwnAuthorisationService, and put their
> real
> > >>> >> > authorization code in that.
> > >>> >> >
> > >>> >> > Take a look at the current
> > >>> org.apache.shindig.opensocial.samplecontainer
> > >>> >> > files to get a feel for how that works for the other
> > > interface/sample
> > >>> >> stuff
> > >>> >> >
> > >>> >> > -- Chris
> > >>> >> >
> > >>> >> > On Jun 19, 2008, at 2:36 AM, Dirk Balfanz wrote:
> > >>> >> >
> > >>> >> >> Hi guys,
> > >>> >> >>
> > >>> >> >> Cassie and David asked me to summarize where we're at with
> OAuth
> > >>> >> >> support in the RESTful server. I volunteered to help out, but
> > have
> > > to
> > >>> >> >> admit that I don't have the full picture yet.
> > >>> >> >>
> > >>> >> >> Here is what I know how to do: I can write a ServletFilter that
> > can
> > >>> >> >> verify incoming signedFetch requests against a list of known
> > public
> > >>> >> >> keys (known to the RESTful server, that is), and then assert
> the
> > >>> >> >> originator of that request (the string passed in
> > > oauth_consumer_key)
> > >>> >> >> to the filters and servlets downstream.
> > >>> >> >>
> > >>> >> >> For anything else (like "real" incoming OAuth requests) the
> > RESTful
> > >>> >> >> server would have to have some sort of notion of user accounts,
> > > which
> > >>> >> >> AFAIK is not the case. I'm saying that because normally, when
> an
> > >>> OAuth
> > >>> >> >> request comes in, you verify the request, and then you map the
> > >>> >> >> supplied OAuth token to an account on your server.
> > >>> >> >>
> > >>> >> >> So I'm not quite sure what it means to "support OAuth" for the
> > >>> RESTful
> > >>> >> >> server (minus the signedFetch part, as explained above), but
> I'm
> > >>> >> >> willing to help implement it if someone can explain it to me.
> :-)
> > >>> >> >>
> > >>> >> >> Any takers?
> > >>> >> >>
> > >>> >> >> Dirk.
> > >>> >> >
> > >>> >> >
> > >>> >>
> > >>> >
> > >>>
> > >>
> > >
> >
>
Re: OAuth support in RESTful server
Posted by John Panzer <jp...@google.com>.
John Panzer (http://abstractioneer.org)
On Tue, Jul 1, 2008 at 2:00 PM, Dirk Balfanz <di...@gmail.com> wrote:
> >> - a request that carries the gadget security token should be able to
> >> do anything the gadget could do
> >
> >
> > Yes, since this is replacing the existing gadget to server wire protocol
> and
> > we don't want to break anything.
>
> Actually, that question (and answer) doesn't make sense to me. Gadget
> don't "do" anything to the RESTful server. Users do.
...via the Gadget/OpenSocial JS APIs. So what's possible via the current JS
API should at least be a subset of what's possible via the RESTful wire
protocol.
>
>
> Dirk.
>
Re: OAuth support in RESTful server
Posted by Dirk Balfanz <di...@gmail.com>.
>> - a request that carries the gadget security token should be able to
>> do anything the gadget could do
>
>
> Yes, since this is replacing the existing gadget to server wire protocol and
> we don't want to break anything.
Actually, that question (and answer) doesn't make sense to me. Gadget
don't "do" anything to the RESTful server. Users do.
Dirk.
Re: OAuth support in RESTful server
Posted by John Panzer <jp...@google.com>.
John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 10:26 PM, Brian Eaton <be...@google.com> wrote:
> A few other comments: what kind of authorization decisions are going
> to be made based on the authentication information from Dirk's code?
> I've heard various use cases:
>
> - a request that carries the gadget security token should be able to
> do anything the gadget could do
Yes, since this is replacing the existing gadget to server wire protocol and
we don't want to break anything.
>
>
> - you should be able to grant read-only access to a user's contacts to
> a third-party via OAuth
Potentially, yes.
>
>
> - you should be able to grant full (read-write) access to a user's
> contacts to a third-party via OAuth
Yes.
>
>
> - the gadget home server should be able to do anything a gadget could
> do, for any user who has installed the gadget
Hmm... I want to say yes, though I wonder about additional in-depth security
measures that might be needed to account for the differences between
security tokens and OAuth tokens, or for server capabilities (a gadget is
not going to legitimately make 1000 requests per second from a single
machine, but a gadget home server could potentially do so.)
>
>
> Are those use cases accurate?
>
> Are they complete?
There are all kinds of other possible limitations one might put on OAuth
tokens or on Consumer Keys besides read only access. (Time limitations, to
pick the most obvious.)
>
>
> Cheers,
> Brian
>
> On Mon, Jun 30, 2008 at 9:58 PM, Dirk Balfanz <di...@gmail.com>
> wrote:
> > Brian left a detailed list of comments on the latest patch for this:
> > https://issues.apache.org/jira/browse/SHINDIG-290
> >
> > Apart from some simple renaming/refactoring suggestions, Brian put his
> > finger on two issues that we couldn't figure out ourselves when we talked
> > about it today, so I wanted to bring them up here:
> >
> > (1) Why do we use (two-legged) OAuth when there is a security token in
> the
> > request? The security token itself is a signed statement of user
> identities,
> > so what's the purpose of stacking OAuth on top of it?
> >
> > (2) With the different ways of establishing the identity of the principal
> > making the request, how exactly do we resolve the case when there are
> > clashes? Right now in the code, I prioritize OAuth token over gadget
> > security token over xoauth_requestor_id. (i.e. only if there is no OAuth
> > token in the request do I even look if there is a gadget security token,
> > etc.). That's a pretty arbitrary decision, and uses the presence/absence
> of
> > paramters in the request as "hints" as to what authentication was
> desired.
> > What if someone happens to include a URL query param named "st" in the
> > request that is not, actually, a gadget security token? Should I signal
> an
> > error because the "security token" didn't parse? Should I see whether
> > instead there is an xoauth_requestor_id parameter present? Wouldn't it be
> > cleaner if the request someone carried an explicit signal with it that
> told
> > the REST server what kind of authentication is being used?
> >
> > Please ponder these questions while I refactor some of the code :-) I'm
> > curious to see what people think...
> >
> > Dirk.
> >
> >
> > On Thu, Jun 19, 2008 at 9:31 PM, John Panzer <jp...@google.com> wrote:
> >
> >> Sounds good. One additional case is where there is a two legged call
> >> with no xoauth_requestor_id, meaning 'do this on behalf of the
> >> Consumer alone, without a particular user making the request'.
> >>
> >> On 6/19/08, Dirk Balfanz <di...@gmail.com> wrote:
> >> > I just had a conversation with John Panzer and David Primmer, and it
> >> cleared
> >> > up some of my misconceptions. I had assumed that the RESTful server
> would
> >> > have to make access control decisions based on the viewer and owner of
> >> > gadgets, and I just couldn't square that with the notion of user
> accounts
> >> on
> >> > that server (i.e. individual users authenticating to the server not as
> >> > "viewer" or "owner", but just as a user).
> >> >
> >> > Anyway, it turns out that the RESTful server, in fact, doesn't have a
> >> notion
> >> > of viewer or owner at all - it only has a notion of the "user making
> the
> >> > request" to the server. So, in light of that, the plan for
> implementation
> >> is
> >> > as follows:
> >> >
> >> >
> >> > - The goal of the oauth servlet filter is to authenticate the user
> >> making
> >> > the request [1]. This will be done in a variety of ways:
> >> >
> >> >
> >> > 1. if the incoming request is from the container's own gadget
> server,
> >> the
> >> > request will be signed using "two-legged" OAuth (aka
> signedFetch),
> >> and
> >> > include a gadget security token. The gadget security token
> includes
> >> > the
> >> > owner and the viewer, expressed in identities native to the
> >> > container. The
> >> > principal that will be represented to the servlets as "making
> >> > the request"
> >> > is the viewer. (If a gadget doesn't like that, it can make a raw
> >> > OAuth call
> >> > to the RESTful API server and use the token of the page owner,
> >> which
> >> > will
> >> > then be used according to point (2) below).
> >> >
> >> > 2. if the incoming request is from a third-party-server that
> uses
> >> > "full" (as opposed to "two-legged") OAuth, then the request will
> >> > include an
> >> > OAuth token that identifies the user. We'll have an interface
> that
> >> > will
> >> > allow containers to map OAuth tokens to their native identities.
> >> The
> >> > principal that will be represented to the servlets as "making
> >> > the request"
> >> > is the principal the OAuth token maps to.
> >> >
> >> > 3. if the incoming request is from a third-party-server that
> uses
> >> > "two-legged" OAuth (aka signedFetch), it won't include a gadget
> >> > security
> >> > token. Instead, it must include a xoauth_requestor_id parameter,
> >> > which names
> >> > the requester principal in a format native to the container.
> >> > The principal
> >> > that will be represented to the servlets as "making the request"
> is
> >> > the
> >> > principal identified in the xoauth_requestor_id.
> >> >
> >> >
> >> >
> >> > - The principal making the request will be communicated to the
> >> servlets
> >> > through the getUserPrincipal() method in the HttpServletResponse.
> >> > getAuthType() will return "OAuth" in each case.
> >> >
> >> >
> >> > What should we do if the incoming request doesn't fall into one of the
> >> three
> >> > categories, or if the signatures don't check out etc? Should the
> filter
> >> let
> >> > the request through to the gadget and just not label them as
> >> authenticated,
> >> > or should the filter return a 401?
> >> >
> >> > Dirk.
> >> >
> >> >
> >> > [1] Note that we're not talking about authorization yet (i.e. rules of
> >> who
> >> > can access what) - this is just authentication, i.e. figuring out who
> the
> >> > "who" is.
> >> >
> >> > On Wed, Jun 18, 2008 at 10:55 PM, Kevin Brown <et...@google.com>
> wrote:
> >> >> On Wed, Jun 18, 2008 at 9:14 PM, Dirk Balfanz <
> dirk.balfanz@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> > A RESTful client is a proxy for a user. Getting the activities for
> a
> >> >>> given
> >> >>> > user doesn't make any sense without ACLs, and you can't have ACLs
> >> > without
> >> >>> > authenticating a user.
> >> >>>
> >> >>> Sure you can. You authenticate the proxy (not the user), and just
> let
> >> >>> the proxy tell you whose user's data they want to access. No need
> for
> >> >>> individual users to have accounts. What am I missing here?
> >> >>
> >> >>
> >> >> Well, you'd still have to grant permission for a client to access a
> >> >> particular user's data. There are two ways to do this:
> >> >>
> >> >> - Whitelist the client for all users, require the client to pass user
> >> >> credentials per request.
> >> >> - Whitelist the client for individual users at "install" time, no
> >> >> per-request user credentials required.
> >> >>
> >> >> The second case is probably simpler for the case of simple
> relationships
> >> >> (@self), but is more complicated to implement queries for friends. In
> >> > either
> >> >> case, you still have accounts, you just shift the burden of doing the
> >> > oauth
> >> >> flow from the client to the provider.
> >> >>
> >> >>
> >> >>>
> >> >>> Dirk.
> >> >>>
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> >>
> >> >>> >> Dirk.
> >> >>> >>
> >> >>> >> On Wed, Jun 18, 2008 at 5:52 PM, Chris Chabot <chabotc@xs4all.nl
> >
> >> >>> wrote:
> >> >>> >> > The practice so far has been to implement the proper code,
> define
> >> >>> >> interfaces
> >> >>> >> > for your data call (a authenticate(user, password) type thing
> in
> >> > this
> >> >>> >> case),
> >> >>> >> > and then make a sample implementation using the
> >> >>> >> > shindig/javascript/samplecontainer/state-basicfriendlist.xml
> file.
> >> >>> >> >
> >> >>> >> > You could just add some user info entries to that xml file, and
> >> then
> >> >>> make
> >> >>> >> a
> >> >>> >> > SampleAuthorisationService.java (that impliments the
> >> >>> AuthorisationService
> >> >>> >> > interface) or something like that, which uses the xml file's
> data
> >> > for
> >> >>> the
> >> >>> >> > authentication.
> >> >>> >> >
> >> >>> >> > Since your in multi threaded java, you can just keep the
> >> > authenticated
> >> >>> >> > sessions in memory, no worries that their destroyed on a
> restart,
> >> > it's
> >> >>> >> just
> >> >>> >> > a demo anyhow.
> >> >>> >> >
> >> >>> >> > Real containers would then replace the config from
> >> >>> >> > SampleAuthorisationService (again that's just an example, not a
> >> real
> >> >>> file
> >> >>> >> > name suggestion) to MyOwnAuthorisationService, and put their
> real
> >> >>> >> > authorization code in that.
> >> >>> >> >
> >> >>> >> > Take a look at the current
> >> >>> org.apache.shindig.opensocial.samplecontainer
> >> >>> >> > files to get a feel for how that works for the other
> >> > interface/sample
> >> >>> >> stuff
> >> >>> >> >
> >> >>> >> > -- Chris
> >> >>> >> >
> >> >>> >> > On Jun 19, 2008, at 2:36 AM, Dirk Balfanz wrote:
> >> >>> >> >
> >> >>> >> >> Hi guys,
> >> >>> >> >>
> >> >>> >> >> Cassie and David asked me to summarize where we're at with
> OAuth
> >> >>> >> >> support in the RESTful server. I volunteered to help out, but
> >> have
> >> > to
> >> >>> >> >> admit that I don't have the full picture yet.
> >> >>> >> >>
> >> >>> >> >> Here is what I know how to do: I can write a ServletFilter
> that
> >> can
> >> >>> >> >> verify incoming signedFetch requests against a list of known
> >> public
> >> >>> >> >> keys (known to the RESTful server, that is), and then assert
> the
> >> >>> >> >> originator of that request (the string passed in
> >> > oauth_consumer_key)
> >> >>> >> >> to the filters and servlets downstream.
> >> >>> >> >>
> >> >>> >> >> For anything else (like "real" incoming OAuth requests) the
> >> RESTful
> >> >>> >> >> server would have to have some sort of notion of user
> accounts,
> >> > which
> >> >>> >> >> AFAIK is not the case. I'm saying that because normally, when
> an
> >> >>> OAuth
> >> >>> >> >> request comes in, you verify the request, and then you map the
> >> >>> >> >> supplied OAuth token to an account on your server.
> >> >>> >> >>
> >> >>> >> >> So I'm not quite sure what it means to "support OAuth" for the
> >> >>> RESTful
> >> >>> >> >> server (minus the signedFetch part, as explained above), but
> I'm
> >> >>> >> >> willing to help implement it if someone can explain it to me.
> :-)
> >> >>> >> >>
> >> >>> >> >> Any takers?
> >> >>> >> >>
> >> >>> >> >> Dirk.
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >
> >> >>>
> >> >>
> >> >
> >>
> >
>
Re: OAuth support in RESTful server
Posted by Brian Eaton <be...@google.com>.
A few other comments: what kind of authorization decisions are going
to be made based on the authentication information from Dirk's code?
I've heard various use cases:
- a request that carries the gadget security token should be able to
do anything the gadget could do
- you should be able to grant read-only access to a user's contacts to
a third-party via OAuth
- you should be able to grant full (read-write) access to a user's
contacts to a third-party via OAuth
- the gadget home server should be able to do anything a gadget could
do, for any user who has installed the gadget
Are those use cases accurate?
Are they complete?
Cheers,
Brian
On Mon, Jun 30, 2008 at 9:58 PM, Dirk Balfanz <di...@gmail.com> wrote:
> Brian left a detailed list of comments on the latest patch for this:
> https://issues.apache.org/jira/browse/SHINDIG-290
>
> Apart from some simple renaming/refactoring suggestions, Brian put his
> finger on two issues that we couldn't figure out ourselves when we talked
> about it today, so I wanted to bring them up here:
>
> (1) Why do we use (two-legged) OAuth when there is a security token in the
> request? The security token itself is a signed statement of user identities,
> so what's the purpose of stacking OAuth on top of it?
>
> (2) With the different ways of establishing the identity of the principal
> making the request, how exactly do we resolve the case when there are
> clashes? Right now in the code, I prioritize OAuth token over gadget
> security token over xoauth_requestor_id. (i.e. only if there is no OAuth
> token in the request do I even look if there is a gadget security token,
> etc.). That's a pretty arbitrary decision, and uses the presence/absence of
> paramters in the request as "hints" as to what authentication was desired.
> What if someone happens to include a URL query param named "st" in the
> request that is not, actually, a gadget security token? Should I signal an
> error because the "security token" didn't parse? Should I see whether
> instead there is an xoauth_requestor_id parameter present? Wouldn't it be
> cleaner if the request someone carried an explicit signal with it that told
> the REST server what kind of authentication is being used?
>
> Please ponder these questions while I refactor some of the code :-) I'm
> curious to see what people think...
>
> Dirk.
>
>
> On Thu, Jun 19, 2008 at 9:31 PM, John Panzer <jp...@google.com> wrote:
>
>> Sounds good. One additional case is where there is a two legged call
>> with no xoauth_requestor_id, meaning 'do this on behalf of the
>> Consumer alone, without a particular user making the request'.
>>
>> On 6/19/08, Dirk Balfanz <di...@gmail.com> wrote:
>> > I just had a conversation with John Panzer and David Primmer, and it
>> cleared
>> > up some of my misconceptions. I had assumed that the RESTful server would
>> > have to make access control decisions based on the viewer and owner of
>> > gadgets, and I just couldn't square that with the notion of user accounts
>> on
>> > that server (i.e. individual users authenticating to the server not as
>> > "viewer" or "owner", but just as a user).
>> >
>> > Anyway, it turns out that the RESTful server, in fact, doesn't have a
>> notion
>> > of viewer or owner at all - it only has a notion of the "user making the
>> > request" to the server. So, in light of that, the plan for implementation
>> is
>> > as follows:
>> >
>> >
>> > - The goal of the oauth servlet filter is to authenticate the user
>> making
>> > the request [1]. This will be done in a variety of ways:
>> >
>> >
>> > 1. if the incoming request is from the container's own gadget server,
>> the
>> > request will be signed using "two-legged" OAuth (aka signedFetch),
>> and
>> > include a gadget security token. The gadget security token includes
>> > the
>> > owner and the viewer, expressed in identities native to the
>> > container. The
>> > principal that will be represented to the servlets as "making
>> > the request"
>> > is the viewer. (If a gadget doesn't like that, it can make a raw
>> > OAuth call
>> > to the RESTful API server and use the token of the page owner,
>> which
>> > will
>> > then be used according to point (2) below).
>> >
>> > 2. if the incoming request is from a third-party-server that uses
>> > "full" (as opposed to "two-legged") OAuth, then the request will
>> > include an
>> > OAuth token that identifies the user. We'll have an interface that
>> > will
>> > allow containers to map OAuth tokens to their native identities.
>> The
>> > principal that will be represented to the servlets as "making
>> > the request"
>> > is the principal the OAuth token maps to.
>> >
>> > 3. if the incoming request is from a third-party-server that uses
>> > "two-legged" OAuth (aka signedFetch), it won't include a gadget
>> > security
>> > token. Instead, it must include a xoauth_requestor_id parameter,
>> > which names
>> > the requester principal in a format native to the container.
>> > The principal
>> > that will be represented to the servlets as "making the request" is
>> > the
>> > principal identified in the xoauth_requestor_id.
>> >
>> >
>> >
>> > - The principal making the request will be communicated to the
>> servlets
>> > through the getUserPrincipal() method in the HttpServletResponse.
>> > getAuthType() will return "OAuth" in each case.
>> >
>> >
>> > What should we do if the incoming request doesn't fall into one of the
>> three
>> > categories, or if the signatures don't check out etc? Should the filter
>> let
>> > the request through to the gadget and just not label them as
>> authenticated,
>> > or should the filter return a 401?
>> >
>> > Dirk.
>> >
>> >
>> > [1] Note that we're not talking about authorization yet (i.e. rules of
>> who
>> > can access what) - this is just authentication, i.e. figuring out who the
>> > "who" is.
>> >
>> > On Wed, Jun 18, 2008 at 10:55 PM, Kevin Brown <et...@google.com> wrote:
>> >> On Wed, Jun 18, 2008 at 9:14 PM, Dirk Balfanz <di...@gmail.com>
>> >> wrote:
>> >>
>> >>> > A RESTful client is a proxy for a user. Getting the activities for a
>> >>> given
>> >>> > user doesn't make any sense without ACLs, and you can't have ACLs
>> > without
>> >>> > authenticating a user.
>> >>>
>> >>> Sure you can. You authenticate the proxy (not the user), and just let
>> >>> the proxy tell you whose user's data they want to access. No need for
>> >>> individual users to have accounts. What am I missing here?
>> >>
>> >>
>> >> Well, you'd still have to grant permission for a client to access a
>> >> particular user's data. There are two ways to do this:
>> >>
>> >> - Whitelist the client for all users, require the client to pass user
>> >> credentials per request.
>> >> - Whitelist the client for individual users at "install" time, no
>> >> per-request user credentials required.
>> >>
>> >> The second case is probably simpler for the case of simple relationships
>> >> (@self), but is more complicated to implement queries for friends. In
>> > either
>> >> case, you still have accounts, you just shift the burden of doing the
>> > oauth
>> >> flow from the client to the provider.
>> >>
>> >>
>> >>>
>> >>> Dirk.
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> >>
>> >>> >> Dirk.
>> >>> >>
>> >>> >> On Wed, Jun 18, 2008 at 5:52 PM, Chris Chabot <ch...@xs4all.nl>
>> >>> wrote:
>> >>> >> > The practice so far has been to implement the proper code, define
>> >>> >> interfaces
>> >>> >> > for your data call (a authenticate(user, password) type thing in
>> > this
>> >>> >> case),
>> >>> >> > and then make a sample implementation using the
>> >>> >> > shindig/javascript/samplecontainer/state-basicfriendlist.xml file.
>> >>> >> >
>> >>> >> > You could just add some user info entries to that xml file, and
>> then
>> >>> make
>> >>> >> a
>> >>> >> > SampleAuthorisationService.java (that impliments the
>> >>> AuthorisationService
>> >>> >> > interface) or something like that, which uses the xml file's data
>> > for
>> >>> the
>> >>> >> > authentication.
>> >>> >> >
>> >>> >> > Since your in multi threaded java, you can just keep the
>> > authenticated
>> >>> >> > sessions in memory, no worries that their destroyed on a restart,
>> > it's
>> >>> >> just
>> >>> >> > a demo anyhow.
>> >>> >> >
>> >>> >> > Real containers would then replace the config from
>> >>> >> > SampleAuthorisationService (again that's just an example, not a
>> real
>> >>> file
>> >>> >> > name suggestion) to MyOwnAuthorisationService, and put their real
>> >>> >> > authorization code in that.
>> >>> >> >
>> >>> >> > Take a look at the current
>> >>> org.apache.shindig.opensocial.samplecontainer
>> >>> >> > files to get a feel for how that works for the other
>> > interface/sample
>> >>> >> stuff
>> >>> >> >
>> >>> >> > -- Chris
>> >>> >> >
>> >>> >> > On Jun 19, 2008, at 2:36 AM, Dirk Balfanz wrote:
>> >>> >> >
>> >>> >> >> Hi guys,
>> >>> >> >>
>> >>> >> >> Cassie and David asked me to summarize where we're at with OAuth
>> >>> >> >> support in the RESTful server. I volunteered to help out, but
>> have
>> > to
>> >>> >> >> admit that I don't have the full picture yet.
>> >>> >> >>
>> >>> >> >> Here is what I know how to do: I can write a ServletFilter that
>> can
>> >>> >> >> verify incoming signedFetch requests against a list of known
>> public
>> >>> >> >> keys (known to the RESTful server, that is), and then assert the
>> >>> >> >> originator of that request (the string passed in
>> > oauth_consumer_key)
>> >>> >> >> to the filters and servlets downstream.
>> >>> >> >>
>> >>> >> >> For anything else (like "real" incoming OAuth requests) the
>> RESTful
>> >>> >> >> server would have to have some sort of notion of user accounts,
>> > which
>> >>> >> >> AFAIK is not the case. I'm saying that because normally, when an
>> >>> OAuth
>> >>> >> >> request comes in, you verify the request, and then you map the
>> >>> >> >> supplied OAuth token to an account on your server.
>> >>> >> >>
>> >>> >> >> So I'm not quite sure what it means to "support OAuth" for the
>> >>> RESTful
>> >>> >> >> server (minus the signedFetch part, as explained above), but I'm
>> >>> >> >> willing to help implement it if someone can explain it to me. :-)
>> >>> >> >>
>> >>> >> >> Any takers?
>> >>> >> >>
>> >>> >> >> Dirk.
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >
>> >>>
>> >>
>> >
>>
>