Let me start by saying that I think this is a bad idea; you want to make knowledge of the shared-secret (the "key to the simulation") a capability; that is, a secret which identifies a particular dataset and where knowledge of the secret is proof of authorisation to access the data set. This is security-through-obscurity and will give you very little control over access to the run data as time goes on: if you think the knowledge has spread, you can't exclude some people who possess the secret without excluding everyone.
But if you insist on doing it, then you don't have to do anything clever at all: merely put the secret into the URL. For example, suppose your datasets are stored under
http://sets.example.com/data/, and that directory is unlistable. Given a set of secrets whose key is, say, b8ab010d69f6008384d39bd3c0efeb0c, store them under
http://sets.example.com/data/b8ab010d69f6008384d39bd3c0efeb0c/; given a set of secrets with a different key, store them under a correspondingly different URL.
If you want a redirector from your main page ("allowed to see the content they ask for when they enter the corresponding key on the homepage") writing it becomes trivial: a one-liner where you enter any key and get redirected to
http://sets.example.com/data/THAT-KEY/. No checking on the "key" need be done; if an invalid key is entered, the user just gets a
404 not found error.
Edit: the fastest way to make a directory unlistable is to put a zero-length
index.html in it. But there are others, as ioctl as pointed out. And as I write this, I realise that all I have described is exactly what Michael Hampton was alluding to in his (extremely, perhaps overly) pithy but accurate comment on your question, above.