[Opensim-dev] Authentication and oAuth

[Diva Canto]

Tommi,

Thanks for your analysis. I don't intend to start a war between 
Capabilitites and ACLs here -- that war has been going on for about 50 
years among people who know a lot more about these things than we do :-)

I do, however, know quite a bit about capabilities in the context of 
OpenSim, so let's clarify some issues.

>  
> 1) If client is given CAPS URL to access something we need to have 
> access list / ownership and user role information in the database to 
> deduce if the user has the right for capabilities he/she is requesting 
> for. CAPS URLs do not remove need to for ownership, roles and ACLs. 
> ACL is theoretically just a list of subjects who have ability to do 
> given operations to an object. You can not even theoretically 
> eliminate this information. You can deduce it from group memberhsip 
> but groups are just another principal who can be added to ACL.
You can never throw the basic *policies* away. They have to be stored 
somewhere. That's not what capabilities try to do.

>  
> 2) Server has to store the CAPS URL information to memory or database 
> which is extra overhead.
Incorrect. Capability URLs can and are generated on the fly. Look, for 
example, at Caps.cs that handles about 1/2 of the Caps we pass to the 
client (the other half is spread in several modules that subscribe to 
OnRegisterCaps). They are also detracted on the fly. We already do this 
dynamic management for the CAPs we pass to the client. That is exactly 
the thing that I like the most. It's not just that the authorization is 
generated on the fly; the service handle itself is dynamic. So the 
service is only there during the appropriate context.

>  3) CAPS URL does not work from server to client as HTTP requests can 
> reliably traverse only from client to server due to NATs and 
> firewalls. So they work only from client to server and server to server.
Linden Lab was able to get over this by devising that very twisted thing 
we all hate called the EventQueue. I suggest you study that, if you want 
to know more. I confess I don't like the EQ either. I understand where 
it comes from -- and that's precisely to overcome the NATs & firewalls 
problem.

In any case, most of what I'm talking about here are capabilities that 
don't involve posting to the client, i.e. what the client can do on the 
region and what the region can do on the inventory. So, no NATs & 
firewalls problem here.

>  4) CAPS URLs are different from authentication tokens. CAPS URLs are 
> authrorization related mechanism which are handed out by the service 
> process like region itself. Region CAPS URLs not help to 
> authenticate or authorize against other service processes like asset 
> providers but you need to first authenticate and authorize 
> against asset provider in which point the asset provider can hand you 
> CAPS URLs.
Yes, of course. CAPs merge authentication with authorization. If you 
know the address, you can use the service. And that's the other thing I 
like about it: it avoids the extra calls for authentication.

>  5) If the life time of the CAPS URL is that of a client session it 
> can be easily be abused by attackers who are sniffing the network traffic.
Of course. But CAPs are dynamic, they come and go. We already have that 
for the Linden viewer's CAPs.

The issue of sniffing is an entirely different issue. Sniffing will 
defeat any security scheme that doesn't use encryption. If you want to 
protect from sniffing, use encryption, always.

 > It looks to me that oAuth might be used to authentication as well so 
it could replace OpenId entirely.

I don't think so. The spec for OAuth clearly says that it doesn't 
concern the authentication steps, which can be done in a number of ways. 
They do suggest, however, that OpenID+OAuth is a good combination.

Crista