John Panzer (http://abstractioneer.org)
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? 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 <[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. > > >>> >> > > > >>> >> > > > >>> >> > > >>> > > > >>> > > >> > > > > > >
