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 _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
