[Opensim-dev] Authentication, take 2: Capabilities

[Diva Canto]

I confess I didn't understand CAPs until they hit me in the head 
yesterday. I always knew the way we were using them was "wrong" in the 
sense that it defeats their purpose of being security devices. Yes, the 
viewer doesn't complain, but they are mute for security purposes. So, 
really, I'm just trying to find the right story for them in the context 
of this black-box viewer, and starting from basic principles. It seems 
that there are many ways of managing capabilities, one of them being 
what we are doing now. I have no idea how Linden Lab does it; but that 
doesn't matter. What matters is that this viewer has some buttons that 
we can push -- not all the buttons we would like, but some.

Maybe capabilities are, indeed, a nifty idea, after one gets passed the 
initial "this is way too complicated" phase. Maybe other viewers would 
use them too, if we have a simple story for them. I really like their 
model of using secret URLs for accessing security-critical services -- 
that's very nice.

I still don't understand this well enough to attempt the very needed 
comparison between capabilities and OpenID tokens. If someone already 
got to that point, please share!

Stefan Andersson wrote:
> Actually, I think getting a 'true' CAPS model going (for those stacks 
> that would use it) would be a major win.
>  
> Getting more user-based stuff moved off the regions as performance and 
> trust bottlenecks would be a major win.
>  
> Regarding the user/inventory service as a bottleneck, I believe that 
> it's no better or worse than having the region as one - walled garden 
> or not, users will come from differing user/inventory servers anyway, 
> and the ability to load balance those services is just as interesting 
> as being able to load balance regions.
>  
> One example is that right now, the user can get 'stuck' in an 
> uncooperative region. As I understand it, with CAPS (if it would work) 
> you could assure that the user at least always can teleport off an 
> unresponsive server - even forcibly teleport him off it - which would 
> be a major win.
>  
> Along the same lines, you could start initiating some actions from a 
> web ui, which would be a major step forward.
>
> Getting some people from the sl-dev list to cooperate closely with us 
> to map out exactly what calls could reliably used over CAPS would be a 
> major win. (No more guessing games - let's get the facts.)
>  
> Regarding the complexity of the solution, I believe that with the 
> current modularization that we're moving towards, and if the CAPS 
> system could be made truly portable over region and grid modules, thru 
> (customized) streamhandlers (there is an LLSDStreamHandler, actually) 
> I think that the complexity could be alleviated - simply put, the 
> trust policy would just be a matter of configuring where the trusted 
> llsd handlers would be instantiated. If it's on a user server, or on a 
> region server, I believe that they could use the same set of CAPS 
> modules, if those modules had an IInventoryService, an IUserService 
> and an ITeleportService proxy or implementation.
>
> That said, CAPS as of now is fundamentally a LLClientView thing, so 
> one probably needs to think about how one would slice that cake.
>  
> But above all, +1 on getting a 'true' CAPS implementation in place. Go 
> Diva! (Godiva?)
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>  
> > Date: Thu, 26 Feb 2009 20:40:04 +0000
> > From: melanie at t-data.com
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] Authentication, take 2: Capabilities
> >
> > 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20090227/3914c993/attachment-0001.html>