Authentication
From SLIS Second Life Wiki
| This Sloodle article is deprecated. It is probably out of date and will not be updated. It continues to exist only for reference purposes. |
|---|
Note: the relevant contents of this article have been re-documented elsewhere: Registration and Enrolment, Prim Password, Object Authorization
Contents |
[edit] Authenticating Objects
If an object in SL needs to access any information on the Moodle server that is not open to users unless they have logged in, it needs to prove to the server that it is allowed to access the information it wants.
[edit] Prim passwords
The original method we implemented for an object in SL to prove that it is allowed to access Moodle is to have the administrator of the Moodle site set a single "prim password" when they install the Sloodle module. This password then needs to be included in scripts that will talk to Moodle. This can either be done by hard-coding the password in a script or by including it in a notecard.
This approach has several drawbacks:
- The administrator needs to find a way to get the password into the scripts.
- If they want to change the password, they need to update all of their in-world objects at once.
- If someone accidentally sets the wrong permissions on an object, there is a risk that the password will leak.
[edit] Object-specific session keys
To avoid the drawbacks of prim passwords, the Sloodle Box uses an object-specific session key to prove to the server that it is allowed to talk to it.
Instead of being hard-coded in the LSL script, or entered into a notecard, the session key is sent to the object by the server.
This works as follows:
- The object has the user click a link to a web page, passing its uuid in the URL, along with a channel that the server should use to send it a session key.
- If the user is not already logged in, they do so here.
- The user is shown a web page asking them to confirm that they trust the object in question.
- The server creates a random key for the object, and sends it using an XMLRPC request to the object using the channel passed in the URL.
- The object receives the session key.
- From then on, whenever it needs to send the server a request which requires the server to trust it, it sends it its uuid, combined with the session key (connected using a pipe character (|).
- If the object wants to get the server to trust other objects as well, it tells the other objects its own uuid and session key. Other objects can then also use the same uuid/session key to connect to the server.
[edit] Checking object authentication in scripts
Whether you're using a prim password or an object-specific session key, the information necessary to authenticate an object is passed from an LSL script to the server in the same way.
In your LSL script, pass the prim password / object-specific session key as an argument called "pwd". (You can use GET or POST, as you prefer.) TODO: This will probably need to change to something like "sloodlepwd" when we finish the style guidelines...
In your PHP script, pull in the authentication library as follows:
require_once('../config.php');
require_once('../locallib.php');
require_once('../login/sl_authlib.php');
To send an error message to any object that doesn't have the required object authentication, do this:
sloodle_prim_require_script_authentication();
[edit] Authenticating Users
Once we have established that we are dealing with a trustworthy object (which we do using the Prim Password or object-specific session key) we can rely on our object in-world to give us accurate information about what avatar it is dealing with. This means that most of the time, we don't need to get the avatar to explicitly login to Moodle.
[edit] Linking avatars to Moodle accounts
Apart from the situation where we don't yet know if an object should be trusted by the server, the only time we need to worry about explicit user logins to Moodle is when they already have a Moodle account, and want to access that account from SL for the first time. There are a couple of ways of doing this:
1) Auto-registration If the Sloodle install has auto-registration turned on when an avatar arrives at a Sloodle Access Checker, a Moodle account is automatically created on the server and linked to the avatar.
2) Open a web page from Moodle To link an avatar to an existing Moodle account, objects like the Sloodle Access Checker and Sloodle Registration Booth will give unknown avatars a link to click, opening a their web browser to a page on their Moodle server with a specially-generated code in the URL. Once they have registered / logged in on Moodle and accessed the page with the code attached, their avatar information will be forever linked with their Moodle account.
3) Jump from the web into SL using a specially-generated SLURL See Login Zone for details of how this is done.
[edit] Checking user authentication in scripts
In your LSL script, if your script needs to confirm who the user is before giving them some data, put their avatar name and key in URL arguments (either GET or POST). The avatar name should be called "avname". The avatar key should be called "uuid".
require_once('../config.php');
require_once('../locallib.php');
require_once('../login/sl_authlib.php');
To make sure that the user is logged in, and return an error if they're not do this:
sloodle_prim_require_user_login();
Once this is done, the Moodle account information will be available in the global $USER object, in the same way it would be if the user had logged in on web.
[edit] Delegating trust from one object to another
When an object rezzes another object, we want the new object to be able to talk to the server in a trusted way immediately, without authenticating itself. Effectively, we are transferring the trust from the parent object to the child object.
To transfer the prim password or object session key securely without the risk of eavesdropping, we pass it to the child object as a parameter.
- TODO: Make the prim password always have to be an integer. At the moment you can put any text into the "prim password" box, which will cause this to fail if you use a prim password here instead of an object-specific session key.
Since the session-key approach requires the child object to attach the uuid of the calling object to the prim password, we also need to communicate to the child object a) something to prove that we are its parent b) our uuid We do this by llSay()ing the 1st 4 digits of the prim password or object session key. The child object compares this with the password that it was given when it was rezzed; If it's correct, it trusts the calling object from then on.
If you want to transfer trust to an object that you haven't just rezzed, I guess you'll have to do one of the following: a) Have the trusted object e-mail credentials to the trustee object. (Risks taking a long time to arrive. b) Relay the communcation through the web server. c) Temporarily make the child object part of a linked set, and send the credentials as a link_message.
Sometimes an object needs to know whether it can trust another object. For example, if a teacher using the Sloodle Box wants to cleanup objects, it needs to be possible for a controlling object to send messages to other objects telling them to llDie(). Ideally, they should only listen to the controller object - if a griefer makes an object and has it send an llDie() command, the griefer's command should be ignored.
To tell an object that it needs to trust another object, we send it the first 4 digits of our prim password or session key.
[edit] Other approaches
TODO
[edit] Passing the necessary information from LSL to PHP scripts
When accessing Moodle data via an HTTP request, pass the following parameters to the PHP script:
- avuuid: The avatar's key
- avname: The avatar's name (This is only needed if the avatar is using a web-connected Sloodle object for the first time, but it's simplest to always pass it.)
- pwd : The authentication string used to prove that the object has permission to talk to the server. (Either a prim password or an object-specific session key)
(TODO: We may need to change the names of these parameters for consistency.)
If the user or the object is not allowed to use the script, and you have correctly called sloodle_prim_require_script_authentication() and sloodle_prim_require_user_login() as described above before printing any data to the browser, the PHP script will pass an authentication error back to your LSL script then exit.
