Sound good Dirk. One comment below. On Thu, Jun 19, 2008 at 5:13 PM, 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?
The request could be in many different phases of the oauth flow, so the filter should be liberal. The spec also allows for unauthenticated requests to go through so we probably should just allow the application of the filter to be configured (I'd suggest a different level than currently as done in web.xml) and it should do something similar to the oauth for spring filters: "This filter attempts to load the OAuth authentication request into the security context using a presented access token. Default behavior of this filter allows the request to continue even if OAuth credentials are not presented (allowing another filter to potentially load a different authentication request into the security context). If the protected resource is available ONLY via OAuth access token, set requireOAuthCredentials to true. " http://spring-security-oauth.codehaus.org/userguide.html#OAuth_Provider_Request_Filters has the concept of one base that handles all oauth related requests, but for different parts of the Oauth flow, uses different filters. OAuthProviderProcessingFilter - base with most of the code ProtectedResourceProcessingFilter - used for accepting access tokens UnauthenticatedRequestTokenProcessingFilter - used for the first part of the 'dance' davep > > 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. >>> >> > >>> >> > >>> >> >>> > >>> >> >
