I think David and Cassie are in violent agreement, for once. The auth filter should handle different kinds of authentication, which includes both OAuth requests, as well as requests carrying a security token. The javascript APIs will always result in calls authenticated by a gadget security token, whereas server-to-server calls from 3rd-party servers may use OAuth, or signedFetch calls asserting a requestor id.
Last time I spoke with Cassie (before I got dragged off to another project), it wasn't quite clear what the common internal representation unifying each of those cases should be. Cassie said she would look at the auth filter code and see whether there was something in there that could serve as a unified auth context. Cassie - are you saying that you decided to use gadget security tokens internally for each of those cases after all? Dirk. On Thu, Aug 14, 2008 at 9:21 PM, David Primmer <[EMAIL PROTECTED]> wrote: > Cassie, could you explain this a little more? what does "always use > it" mean? This is obviously just an implementation choice, there's > nothing in the spec about it, in fact, the spec says that requests > will be authenticated with oauth. Why would shindig's api server be > tied to the gadget token any more than any other bag of attributes? > > davep > > On Thu, Aug 14, 2008 at 6:52 PM, Cassie <[EMAIL PROTECTED]> wrote: >> This is most definitely not true. >> We will always use the security token from the javascript apis. >> >> Shindig handles the st on the url, oauth requests, anon requests and >> anything any container feels like injecting with guice. >> >> - Cassie >> >> >> On Thu, Aug 14, 2008 at 6:43 PM, David Primmer <[EMAIL PROTECTED]>wrote: >> >>> Dirk may want to step in here, as he had plans for how the auth filter >>> should mediate here. But the last explanation I got of the whole st= >>> gadget security token on the url was that it was deprecated and should >>> go away soon. This code should be removed from the java impl and >>> others should not follow its lead here. It's also the case, as bob >>> points out, that the auth context has a lot of variables and needs >>> some 'internal resolution' within the auth processing filter(s)to >>> happen before you can ask a question like, "what is the id of the >>> 'viewer' so you can pass it back to the data access layer. >>> >>> more info here >>> https://issues.apache.org/jira/browse/SHINDIG-290 >>> >>> (the diagram i wrote is wrong as it assumes a the rest server would be >>> sent a gadget security token.it shouldn't that token is only for >>> communication between the container page and gadget server.) >>> >>> davep >>> >>> On Thu, Aug 14, 2008 at 4:37 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: >>> > We could create strongly types security tokens to represent each of these >>> > cases. The use of isXXX functions goes some way to achieving this but >>> maybe >>> > not far enough. There certainly needs to be more information in the API >>> > specs about that various mappings. >>> > On Thu, Aug 14, 2008 at 3:50 PM, Robert Evans <[EMAIL PROTECTED]> >>> wrote: >>> > >>> >> It seems that these concepts should be given more of a first class >>> >> status than just deduced from the populated fields. Maybe it's not a >>> >> big issue, but I can imagine developers forgetting a field, and >>> >> getting back different data than they expected. Also, it might be >>> >> worth having this in a big matrix with the meaning of the OAuth >>> >> parameters (which get translated into a SecurityToken by the >>> >> AuthFilter), since there is so much overlap in domain. >>> >> >>> >> Bob >>> >> >>> >> On Thu, Aug 14, 2008 at 2:56 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: >>> >> > Hi, >>> >> > >>> >> > Id like to propose that we define more tightly the semantics of the >>> >> fields >>> >> > on SecurityToken's and what consumers of its information should infer. >>> >> The >>> >> > security token basically carries viewer-id, owner-id and app-id as its >>> >> three >>> >> > fundamental pieces of data. >>> >> > >>> >> > I'd like to propose the following semantics for permutations of those >>> >> > fields, some of which is just re-hashing what we already do >>> >> > >>> >> > *1. (app-id=<not set>, viewer-id=<not set>, owner-id=<not set>)* - >>> This >>> >> is >>> >> > the case of anonymous access to the API. This would only be allowed to >>> >> > access public resources. >>> >> > >>> >> > *2. (app-id=<some id>, viewer-id=<some id>, owner-id=<some-id>)* - >>> This >>> >> is >>> >> > the common gadget rendering case where an application is allowed to >>> make >>> >> API >>> >> > calls acting-on-behalf of the viewer who is the authenticated >>> principal. >>> >> > This token is typically quite a restrictive, for example this token >>> may >>> >> not >>> >> > allow modification of the owner-id's AppData. >>> >> > >>> >> > *3. (app-id=<some id>, viewer-id=<not set>, owner-id=<not set>) *- >>> The >>> >> is >>> >> > the case of a trusted third-party which can assert ownership of the >>> >> > specified application. This token would typically grant greater access >>> >> than >>> >> > the prior one, e.g it may grant access to update the AppData for any >>> user >>> >> > that has granted permissions to the specified application. >>> >> > >>> >> > *4. (app-id=<not set>, viewer-id=<some id>, owner-id=<not set>)* - >>> The >>> >> is >>> >> > the case of a call to the API authenticated as the viewer. This would >>> be >>> >> > common for desktop applications that ask users for user/pass to >>> >> authenticate >>> >> > calls on the API. This token may grant greater access to the users >>> >> profile >>> >> > information than any of the prior ones. >>> >> > >>> >> > It would make a certain amount of sense to codify each of these cases. >>> >> > Currently 1 is defined as 'isAnonymous' in our interfaces. Potential >>> >> names >>> >> > for 2-4 are >>> >> > >>> >> > 2. isApplictionOnBehalfOfUser >>> >> > 3. isApplication >>> >> > 4. isAuthenticatedUser >>> >> > >>> >> > Thoughts? >>> >> > >>> >> > -Louis >>> >> > >>> >> >>> > >>> >> >
