see below.
Peter Saint-Andre wrote:
> On 1/21/10 10:16 PM, Jason Eacott wrote:
>>
>>
>> Peter Saint-Andre wrote:
>>> On 1/21/10 6:08 PM, Jason Eacott wrote:
>>>
>>>> Oauth is all about impersonating other users, thats all it does!
>>> False. OAuth is about delegating access to protected resources so that
>>> another entity can have restricted authority to perform a given task
>>> (the canonical example is granting a printing service access to your
>>> online photos). OAuth is not about impersonation, it is about delegated
>>> authorization. Those two things are very different.
>>>
>>> Peter
>> fair enough,
>> but in practice is there really much distinction? granting a printing
>> service access to photos, granting another service limited access to my
>> private xml data store, granting another service to create pubsub nodes
>> with me as the owner, etc.
>> The upshot of it all is that after authority is delegated, the
>> authorised proxy is allowed to act on the users behalf for whatever it
>> has been given permission to do.
>> For me I dont see the difference.
>
> If I show up at your bank with a Jason Eacott constume on, fake ID,
> etc., and withdraw all your funds, the bank thinks that you have
> completed a legitimate transaction.
>
> If I show up at your bank with a notarized letter signifying that I have
> power of attorney and you have explicitly authorized me with the bank to
> act on your behalf in limited ways, then if I transfer some funds to
> another account the bank won't think that you did it, they will think
> that I did it with authorization.
>
> I continue to think that impersonation and delegation are quite
> different relationships.
>
>> I didn't state categorically in this
>> last post that the proxy can only act in limited ways (if the user
>> offers only limited authority to the service), but I dont think it
>> changes the fact that at the end of the process a service is allowed to
>> act on behalf of a user (various oauth api's make this feel very much
>> like simply switching user hats - now I'm user x. do ...).
>
> It feels that way, but under the hood it's not, and from a security
> perspective it had better not be the same.
>
>> my point is that if xmpp embraced something like this then components
>> and external services could actually use things like the private xml
>> storage of any user that offered authority, but instead the only options
>> I know for such a service is to either reinvent xml data storage, deploy
>> as a client app, or convince its users to handover user credentials.
>
> Correct at present.
>
> What does XEP-0235 not give you? How does it need to be expanded? IMHO
> you are pointing to the fact that this model is not yet in code.
great question!
actually I have built code, but it only solves a small part of the problem.
I'm not sure a modified xep can fix this (maybe I'm wrong though).
ok, so a scenario to think about:
lets say I build a simple xmpp component based search service - some
google like variant perhaps - and lets say that part of this service
involves storing the last search criteria for each user, so private xml
data seems ideal.
Lets also now say that I want to make my search service available for
simple mobile devices - midp1+http only. so I install an esb with the
appropriate protocols for translation. (I've tried to keep this simple -
an actual web service with html ui is also another obvious hop here)
the device is simple so implementing the bosh protocol directly is too
expensive in terms of memory and cpu(battery).
at this point there are choices: let the esb establish connections as
real xmpp users as required.
Establish a single connection and use oauth or similar to carry the real
intended user info.
the first option requires that the esb knows the users real xmpp
credentials, its totally unscalable, the search service cant access
private xml storage, and the esb is free to do anything it wants on the
xmpp network because as has so rightly be pointed out here unfettered
spoofing isnt good.
the second option is better - the user authorises the esb to interact
with my service via oauth, so now at least we havent sold the farm by
giving real credentials to anyone. the esb could choose to implement its
own (different) user/pass and mappings etc but its not nececarry.
but as in the first case, the service itself is still powerless to save
the search criteria. It could of course save it locally, but thats far
from ideal, and not the point of this discussion. The service may also
have real reason to want to leverage many xep or other non xep component
services in this way.
I think thats pretty much the problem I'd like to see solved, and I
think my initially proposed flow addresses this - but it doesnt address
the proxy identity tracking part. the xmpp server is already the
identity gatekeeper, and xmpp messages are always sent from a given
users server, so for me it made sense to route to be proxied messages
back to that server for verification. but how you get all the remote
components & users to know and trust a given action I'm not sure.
perhaps, to let the remote servers know - an xml element added to the
message indicating the originating caller would do it.
but how u let those components verify that I dont know. - but is it
important? I say this only because in this flow, the users own server
would have verified the identity and authority of any such request
before sending it anyway.
the user has full control, and servers still cant send any messages from
remote domains.
there are probably huge problems with this, so try to temper your
responses please :)
Cheers
Jason.
>
>> previous posts in this thread have said there are other options
>> available but I don't yet know what they are.
>
> We really have not worked on this problem much, as Pedro points out. So
> I'm sure there are very wide gaps here between what exists and what you
> feel you need (for what application, by the way?).
>
> Peter
>
