So if you take a look at the new code we have a very different structure from the AuthServletFilter that was submitted from a patch. The current filter allows for pluggable handlers - and asks each handler to produce a SecurityToken from the request in turn. The first one that returns a token wins and that token is passed on down.
Louis' email was asking how we can encode more information into the SecurityToken - the answer to this may result in a new auth object - that part doesn't matter as much as long as we have one object that we get all the info from. In my last response I was specifically referring to David's comment about the st param on the url going away. So the java code is not forced in any way to respect the url param but the javascript code inside Shindig uses the st param and there is no plan for it to stop using the st param. Which means that the st param on the url is not considered obsolete, deprecated, or wrong - I just wanted to make sure that is clear with everyone. David, you are correct, this is an implementation detail and not a spec detail, but within Shindig we don't currently have any plans to change the impl. Anyway, the current auth filter works great and is easily pluggable. Let's get this thread back on track by discussing the SecurityToken object itself and what fields it needs to contain in order for the social code to work most cleanly. On that original question - Louis, I think that sounds alright but maybe we should try writing some code with that new model to see how well it fits the use case? - Cassie On Thu, Aug 14, 2008 at 10:55 PM, Dirk Balfanz <[EMAIL PROTECTED]>wrote: > 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 > >>> >> > > >>> >> > >>> > > >>> > >> > > >
