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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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. >> >>> >> > >> >>> >> > >> >>> >> >> >>> > >> >>> >> >> >> > >> >
