Security token semantics for implementors of RESTful API

[Louis Ryan <lr...@google.com>]

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

Re: Security token semantics for implementors of RESTful API

[Cassie <do...@apache.org>]

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 <di...@gmail.com>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 <da...@gmail.com>
> 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 <do...@apache.org> 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 <david.primmer@gmail.com
> >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 <lr...@google.com> 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 <bo...@google.com>
> >>> 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 <lr...@google.com>
> 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
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >
>

Re: Security token semantics for implementors of RESTful API

[Dirk Balfanz <di...@gmail.com>]

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 <da...@gmail.com> 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 <do...@apache.org> 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 <da...@gmail.com>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 <lr...@google.com> 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 <bo...@google.com>
>>> 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 <lr...@google.com> 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
>>> >> >
>>> >>
>>> >
>>>
>>
>

Re: Security token semantics for implementors of RESTful API

[David Primmer <da...@gmail.com>]

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 <do...@apache.org> 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 <da...@gmail.com>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 <lr...@google.com> 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 <bo...@google.com>
>> 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 <lr...@google.com> 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
>> >> >
>> >>
>> >
>>
>

Re: Security token semantics for implementors of RESTful API

[Cassie <do...@apache.org>]

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 <da...@gmail.com>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 <lr...@google.com> 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 <bo...@google.com>
> 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 <lr...@google.com> 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
> >> >
> >>
> >
>

Re: Security token semantics for implementors of RESTful API

[David Primmer <da...@gmail.com>]

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 <lr...@google.com> 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 <bo...@google.com> 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 <lr...@google.com> 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
>> >
>>
>

Re: Security token semantics for implementors of RESTful API

[Louis Ryan <lr...@google.com>]

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 <bo...@google.com> 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 <lr...@google.com> 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
> >
>

Re: Security token semantics for implementors of RESTful API

[Robert Evans <bo...@google.com>]

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 <lr...@google.com> 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
>