John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 10:26 PM, Brian Eaton <[EMAIL PROTECTED]> 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 <[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. > >> >>> >> > > >> >>> >> > > >> >>> >> > >> >>> > > >> >>> > >> >> > >> > > >> > > >
