On Mon, Jun 30, 2008 at 11:44 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
> Ok, Take 2, then, on the proposal. How about this: There are two filters for
> authentication. First is an OAuth filter, second is a gadget-security-token
> (GST) filter.
Why should there be two filters? You're already verifying the GST in
the OAuth filter, seems like it is just a matter of moving that code a
bit.
Either way, both filters should provide the same Principal
subinterface for use by the authorization code.
>
> - The OAuth filter does the following:
>
>
> 1. 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.
This won't work for several of the use cases discussed in this thread,
e.g. access to a user's contacts, but not their other data, or
read-only access to contacts.
A more useful mapping would be from oauth token to OAuth consumer
identity, since the OAuth consumer is the one making the request. The
question shouldn't be "Does user X have permission to modify user X's
contacts", it should be "Does consumer K have permission to modify
user X's contacts"
My take? Provide the entire OAuth message in the DelegatedPrincipal
object, perhaps with some convenience methods to get the OAuth
consumer key and OAuth access token. That way the authorization code
has plenty of flexibility in the businss logic. Put another way: the
OAuth filter proves the message is authentic, and other code is
responsible for deciding what that message should accomplish.
>
> 2. if the incoming request is from a third-party-server that uses
> "two-legged" OAuth (aka signedFetch), it won't include an OAuth 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.
Same problem as above, permissions are a subset based on the OAuth
consumer key and the OAuth requestor id. The same solution as above
should work.
But you'll want to distinguish between the two cases: it is quite
possible that two-legged OAuth will need different authorization rules
than full OAuth.
> 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.
getAuthType should distinguish between gadget security token, full
OAuth, and two legged OAuth.
getUserPrincipal should probably return some ornate string that no one
will actually use for anything. This is too complicated to fit into a
single user identity, so we should discourage people from using
getUserPrincipal for anything except debugging. How about a principal
name like "oauth_consumer_key=<consumer>&oauth_token=<token>"
The actual authorization should be based on calls on the principal object like:
getAuthType
getOwner, getViewer, getGadget
getOAuthMessage().get("oauth_consumer")
getOAuthMessage().get("oauth_token")
etc...
(I know that this is annoying, but it is also the only way to
implement the business logic.)
