[Opensim-dev] Authentication, take 2: Capabilities
Diva Canto
diva at metaverseink.com
Thu Feb 26 20:49:12 UTC 2009
Here's the thing: the CAPs giver can define whatever it wants as CAPs
providers. So I think what we have currently is a subset of what I'm
saying below. Specifically, the CAPs giver can delegate CAPs to trusted
regions.
But obviously, we need to think more about this. My main goal here is to
flip the tables and see what under.
Melanie wrote:
> It sounds complex, and also sounds like something that would
> overcomplicate scenarios where there _is_ trust. It would be great
> for a "untrusted grid" scenario, but how would a trusted grid
> scenario (e.g. walled garden) be built to be more efficient and less
> bottlenecky? This setup creates a SPF for every user. Not good.
> Becoming disabled/unresponsive because the user server or home
> region fails? that is more brittle than LL!
>
> Melanie
>
> Diva Canto wrote:
>
>> [Warning: long and heavy-duty stuff here]
>>
>> So, I just had an insight this morning as I woke up. We've scratched our
>> heads about this fuzzy black-box component called "the viewer", and how
>> horrible it is for open systems because it assumes the regions proxy all
>> the security-critical data etc etc.
>>
>> Well, the insight is that maybe this black-box component is not as bad
>> as we think; maybe we're just not using it the right way. All our
>> knowledge has come from poking at it with things like gridproxy and best
>> guesses, which has taken us a long way. But none of us has seen what it
>> actually does. I still don't know what it does, but now I'm convinced we
>> can go a lot further with this viewer in order to make it safe in open
>> systems. I'm hopeful, at least :-)
>>
>> The key: capabilities.
>> The implications to OpenSim: enormous.
>>
>> First a bit of history about CAPs in OpenSim.
>>
>> From what I understand, CAPs in OpenSim has been a reactive process of
>> "The Lindens added X over CAPs; let's find the simplest possible thing
>> that makes the client happy." As a result, when I first started looking
>> at TPs etc. there was one single CAP seed per agent that was passed
>> around throughout all the regions that the agent visited, and that was
>> used to set up CAP URLs with virtually identical paths. The use of
>> capabilities as security devices was completely defeated; yes, the
>> client wasn't unhappy, it worked, but we were far away from implementing
>> CAPs-as-secrets.
>>
>> Then I started fiddling with that, and changed things so that each
>> region has its own CAPs seed per agent. However, the purpose of CAPs for
>> security is still completely defeated, because the regions know each
>> other's seed caps. In fact, seed caps are being generated by the
>> departing regions for the receiving regions so that we can implement
>> agents transfers the way we do now:
>> eq.EnableSimulator(reg.RegionHandle, endPoint, avatar.UUID);
>> eq.EstablishAgentCommunication(avatar.UUID, endPoint, ***capsPath***);
>> eq.TeleportFinishEvent(reg.RegionHandle, 13, endPoint, 4, teleportFlags,
>> ***capsPath***, avatar.UUID);
>>
>> The departing region that runs the code above needs to know the caps
>> seed path of the receiving region, so it can send it to the client.
>> Again, completely defeats the purpose of CAPs being secrets.
>>
>> Let's rewind. The idea behind caps is that they are opaque URLs that are
>> a shared secret URL between the CAP giver, the CAP receiver, and the
>> CAP-function provider. The CAP receiver is the viewer. The viewer
>> understands (i.e. has semantics for) a number of capability-enabled
>> functions such as the seed itself, Event Queue, NoteCard and Script
>> updates, ... and, yes, even Inventory access! As far as we know, the
>> semantics is defined by a mapping from pre-defined names to the CAP URLs
>> that we send to the viewer. For example, whenever the viewer wants to
>> update a notecard in the agent's inventory, it simply posts to the URL
>> we gave it associated with the name "UpdateNotecardAgentInventory". The
>> viewer doesn't know what's behind that URL; that's up to (a) the
>> capability giver to establish who the provider is and (b) to the
>> capability provider to implement.
>>
>> OK, so the fundamental flaw in our thinking so far is that the *regions*
>> are both, and always, the CAPs generators/givers and the CAP-function
>> providers. (With one notable exception of the initial CAPs seed, which
>> is generated by the UserLoginService for the first region). This is
>> flawed because we can't trust the regions in general. We definitely
>> can't have a single seed being passed around the regions, and we also
>> can't have the departing region generate the CAPs seed for the receiving
>> region.
>>
>> Furthermore, and this is even more radical, we also can't have the
>> regions post events to the Event Queue! I'll get to this a little
>> further down.
>>
>> The right way of thinking, at a high level, is this: the CAPs
>> generator/giver must be a trusted component. We can't trust regions in
>> general (only a few home ones), so we can't let CAPs be handled by the
>> regions in general -- period. In an open grid system we can only trust
>> the User server, and the servers that it trusts such as the home region
>> and the user's inventory server. Hence the user server is the only
>> component that should ever give out CAPs URLs (or delegate that function
>> to a trusted component).
>>
>> *Implications*
>>
>> The implications for how we do things are enormous. For example,
>> teleports. The right way of doing TPs safely should be to have the
>> user/presence/homeregion server do them, not the regions. Something like
>> this:
>>
>> - client requests TP on the untrusted region A to untrusted region B
>> - untrusted region A may do whatever it wants with that request, but
>> let's start by the base case: it complies with the request
>> - region A notifies *the user server* that the agent wants to TP to region B
>> - User server posts EnableSimulator for B on *a trusted* Event Queue
>> - User server posts EnableChildAgent for B on that queue, with a CAP
>> seed *pointing to a trusted component*, so that precludes B
>> - Client gets that, and invokes the seed cap to get all the CAP URLs
>> - User server proceeds to spawn the agent in B
>> - User server posts TeleportFinish on the trusted queue with that same
>> CAP seed
>> - Client does CompleteMovementIntoRegion, as normal
>>
>> Attachments should also be posted by the User server onto B, and not by A.
>>
>> [In all of the above, read "user server" as "user server or a trusted
>> component"; it could be the user's home region, for example; so there
>> could be only one Event Queue ever, at the home region. Yey!]
>>
>> Another critical example: inventory. The CAP URL for this should be
>> pointing directly to the Inventory server, not to the regions. I
>> understand that inventory over CAPs had some issues in the past. I just
>> fiddled with it this morning, and it's working -- I'm sure there are
>> problems that I'm not seeing here on my standalone, but the basics seem
>> to be there. That is, I gave it this:
>>
>> m_capsHandlers["FetchInventoryDescendents"] =
>> new RestStreamHandler("POST", capsBase +
>> m_fetchInventoryPath, FetchInventoryRequest2);
>>
>> and the viewer compliantly posted to this URL when I accessed my
>> inventory, instead of using UDP. So there's something here waiting to be
>> used.
>>
>> *Bottom line*
>>
>> There are still a lot of things that I don't know if/how they work, and
>> lots and lots of details that are unclear, so I'm not sure this is
>> feasible. BUT -- I just wanted to launch the idea of turning the tables
>> upside down on how we do things, using CAPs in a completely different
>> way than we have been using them. This CAPs mechanism follows the
>> general idea of moving functions away from the regions, which is our
>> main goal for secure interoperability. I'm not sure it's "the right"
>> mechanism, but we really haven't explored it at all.
>>
>> Your thoughts appreciated, especially from those who have tried using
>> inventory over CAPs before and from those who know the LL servers from
>> the libomv end and from everyone else who knows about these things.
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> 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/20090226/39ef6bf8/attachment-0001.html>
More information about the Opensim-dev
mailing list