[croquet-dev] Selective access

That's actually a fairly deep question.  I'll give you three answers.

Answer 1:
Without doing any programming yourself, there isn't a way to  
selectively allow access to a particular user to a particular portal.

Answer 2:
If UI-level access control is good enough (eg: you're not worried  
about what an attacker can do with a hacked version of your client),  
then it is not difficult to add an extra test to (for example) the  
beginning of #testEnter:avatar: that answers false the avatar's  
userID against a list of authorized avatar IDs.

Answer 3:
If the level of security just described is not high enough, then it  
gets more complicated.  In this case, you really want to only allow  
access to the island to authorized parties.  This means that  
unauthorized users would not be able to see the world that lies  
"beyond the portal", because they wouldn't have a replicated copy of  
the island (there are a number of strategies that can ameliorate this  
situation, such as providing a low-res video stream, or a 3-D model  
in the postcard that shows the "entryway" into the world without  
syncing the whole world).  The portal would do a similar test as in  
Answer 2, but an attacker couldn't circumvent the test with a hacked  
client.

Hope this helps,
Josh


On Feb 6, 2007, at 2:52 AM, Kiran wrote:

> Hi,
> In Croquet, all the TPortal are accessible to anybody present in  
> the Croquet World.
> Is there a way out to selectively allow access to a particular user  
> to a particular portal?
>
> Thanks
> Kiran

>Answer 3:
If the level of security just described is not high enough, then it gets
more complicated.  In this case, you really want to only allow access to the
island to authorized parties.  

Josh, thanks for answering Kiran. I am still unclear on the most secure way
to "only allow access to the island to authorized parties" and in my case I
am looking specifically at having a user/password login combination that the
authorized player has to purchase on a web site (and to check the login
against a mysql database). I know how to implement that, but not
specifically how to do it in croquet or what security concerns croquet might
present.

In my project a croquet space "lobby" would be available for free (and other
croquet users could hopefully find and hook up with my master copy of this
space via their own croquet projects) and then my private pay-to-play
islands would be connected to that free and open lobby space. It would be
analagous to having a public home page on your web site that anyone can link
to with the url but disallowing direct linking and login access to paid
subscription content in some part of the site. Any suggestions on how to set
this up in croquet so that someone familiar with croquet programming can't
easily get around it? I don't need air-tight security here, just some idea
where to begin setting up a commercial space in a croquet project (a paid
access portal). I am unsure how to secure access when the client is
processing the login rather than a central server application that only I
can update. Anyone else doing this kind of thing?

And a more basic set of questions: what version of Fedora Core will run a
croquet master space AND how do remote machines running croquet participant
spaces find/see the master on the server? I don't want to experiment by
allowing shared access on my office or home network but I have dedicated
servers I could set up to run a croquet master space if I knew what
environment was needed and how to configure ports. Any tutorials or ideas?

Thanks,
Kelly

On Feb 6, 2007, at 1:27 PM, Kelly Rued wrote:

My response is made in the context of the Croquet Collaborative  
codebase (http://www.croquetcollaborative.org), both due to my higher  
familiarity with the codebase, and because it demonstrates some  
functionality that is not present in the "raw" 1.0 SDK.

When you run it, you will notice that when you click to open a portal  
for the first time, it takes some time for the world behind to appear  
(in the interim, the portal appears as a mirror; you can imagine  
other effects like a load progress-bar, etc.).  This is because the  
world behind the portal lives on a separate island that is not yet  
being replicated on your machine.  When you open the portal, you set  
in motion a chain of events that includes:
        - determining the router for the world beyond the portal
        - authenticating yourself to that router
        - receiving a snapshot of the island for that world
        - installing the island, and beginning to process events

You will want to augment the authentication procedure in some way.  
Just as an example, you could have a "key-chain" directory that  
contains public/private key pairs.  When you open a portal, the  
router could give you a challenge that you can only meet successfully  
if you have the proper private key (just your standard public key  
crypto).

Unfortunately, I can't point you to code that does this, because that  
code doesn't exist.  But TSimpleRouter should give you enough of an  
example to implement other authentication schemes (or you might  
decide that it is good enough on it's own, at least for a prototype),  
and the Croquet Collaborative code demonstrates how to load islands  
on demand.  From what I can see, this is a pretty good starting point  
for the use case you describe below.

With respect to running a "master space" (which, I should point out,  
is not a core Croquet concept... others have experimented with  
storing a description of a world on a server; the first person who  
tries to join the world creates the world from this description  
rather than syncing with an always-running island replica) on Linux,  
I think that pretty much any version of Fedora should work.  The  
persistent copies of Croquet Collaborative islands run on FreeBSD,  
which is definitely a less common Squeak/Croquet platform.  I would  
again recommend looking at the Croquet Collaborative codebase, which  
goes to some lengths to allow running a "headless" (no OpenAL/OpenGL)  
Croquet image; this has the dual benefits of reducing the  
computational load on the "server", and of reducing the dependencies  
you would otherwise have on a properly installed OpenAL and OpenGL.

Josh