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