[Opensim-dev] Authentication, take 2: Capabilities

Sat Feb 28 17:17:36 UTC 2009

Dear Diva:

As always, I have the highest of respect for your logic and would encourage your vision. It seems altogether reasonable to me.

As we move forward, considering those use cases in the future that are not currently very active such as standalone regions or arrays that also participate in the HyperGrid notion is good also.

On the OSGrid case, even though OSGrid is near and dear to my heart, I have to take a logical step back and say that OpenSim should evolve in a manner that makes it most useful for educational, scientic and commercial applicatons and development should not be pertubated for OSGrid's benefit.

Having said that, I can also say that OSGrid desires to continue to be right at the leading edge of OpenSim development and support that development as much as possible while a community continues to develop. These two OSGrid goals have a certain amount of tension between them, but so far this has been very positive tension.

Charles

________________________________
From: Diva Canto <diva at metaverseink.com>
To: opensim-dev at lists.berlios.de
Sent: Saturday, February 28, 2009 8:53:48 AM
Subject: Re: [Opensim-dev] Authentication, take 2: Capabilities

I've come full circle on this issue of security and the Linden Viewer, 
and I have something to propose.

First, my conclusions:

(1) Capabilities are a fantastic idea for secure open systems. <3's it!
(2) The Linden viewer, as it's going in practice, is unsafe for an open 
Virtual Worlds system.

My proposal:

(a) Let's design OpenSim around the organizing concept of capabilities. 
We're already half-way there, thanks to the Linden Viewer, even if it 
took us there kicking and screaming. Designing OpenSim around the 
organizing concept of capabilities means that no sensitive service 
should ever be exposed face-value on the web; it should always be 
exposed behind a capability URL. For example, the inventory access 
services that we have now are fundamentally unsafe. Someone tried to add 
an authorization step (session id), but that failed badly and was 
abandoned. Melanie and others doing walled-gardens rely on placing these 
services behind firewalls or in obscure places that only 2 or 3 people 
know the address. Security through obscurity works well in certain 
cases, but it's fragile and it simply doesn't work in open systems. It 
will not work for the Hypergrid.

By placing the services behind capability URLs, instead of face-value 
URLs, we can expose the servers on the public web and still be sure that 
only authorized components will access them -- this, without having to 
verify the credentials of the caller over and over again with expensive 
remote calls: the simple fact that the caller knows the secret URL is 
enough for authorization.

What this means is that regions must gain Capabilities to access both 
the users' agents and the users' services as the users move into them. 
Or not. Right now, we're giving the regions all the capabilities, some 
explicitly (for the users' agents), some implicitly (services). The 
explicit ones are those that the regions get by calling the SEED Cap URL 
-- which mainly serves to get the very important cap for the viewer's 
Event Queue. The implicit ones are those currently hard-coded: the 
inventory services, the asset services, IM, etc. We should make those 
also explicit; then it will be up to the *policies* (a separate thing) 
to define which components get which caps.

We should create a Capabilities service, which can be run off a separate 
server (or the user server -- again, I wish this was configurable too!). 
This Caps service will be responsible for managing the capabilities 
pertaining to users and regions within one domain of trust (UGAIMs). So, 
users and regions who log in to this domain of trust will be given 
initial capabilities, and these may be expanded and retracted  as 
certain actions occur.

Different domains of trust may have different capability policies. For 
example LCO's Cap service may very well give all of its regions all the 
capabilities to access the backbone services directly, as well as the 
capability to access all agents' Event Queues, no questions asked. 
OSGrid may not give its regions the capability to access the inventory 
service while still giving its regions the capability to access the 
agents' Event Queues; and for regions that are not registered in OSGrid, 
OSGrid may very well not give them the capability to access the users 
agents' Event Queues.

(The EQ's are the key element in Teleports; if a region doesn't have 
access to the viewer's EQ, it cannot teleport the agent. The user, 
however, may have an agent in the home system with an open EQ to the 
viewer, so that Teleports can happen controlled by the home system -- 
this is the cool new Teleport procedure that I'm going to experiment with)

Capabilities have an additional positive side-effect: they force us to 
slice monoliths into small, independent services ("capabilities") 
explicitly mapped to names, that can then be implemented by different 
components. Very much in line with our design principles.

(b) With respect to the limitations of the Linden Viewer, there's only 
one way forward: a reference web application that replaces the 
security-critical functions that the Linden viewer is incapable of doing 
in a secure manner. These include: inventory access, agent transfers and 
IM. This web application should use capabilities fully and properly. It 
can be accessed using the embedded browser, so immersion shouldn't 
suffer that much.

I will gladly start the work on (a) right now if there's general 
agreement that this is a good way forward.

Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090228/32e4206f/attachment-0001.html>