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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> On Wed, Jun 18, 2008 at 9:14 PM, Dirk Balfanz <[EMAIL PROTECTED]> >> 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 <[EMAIL PROTECTED]> >>> 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. >>> >> > >>> >> > >>> >> >>> > >>> >> >
