[Opensim-dev] Authentication, take 2: Capabilities

Sun Mar 1 03:03:23 UTC 2009

So that you know, I have now been able to perform teleports of the user 
using the EventQueue of a child agent in another region, another 
machine. A total hack just to see if this was feasible. It is!

This really brings into question our understanding and use of the EQ. 
It's not just security, although security is my main focus right now; 
the EQ is a very expensive element, as you know 
(http://opensimulator.org/mantis/view.php?id=2946). What my hack shows 
is that this client allows us to have one EQ per user and always in the 
same place, if we want. As far as I can guess, the EQ, being a 
Capability, doesn't even need to be associated with child agents; it can 
be a resource somewhere.

Crista

Charles Krinke wrote:
> 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 <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/cab01c6a/attachment-0001.html>