-
Notifications
You must be signed in to change notification settings - Fork 3
Tutorial 01 Terminology
CernVM WebAPI provides an abstraction for interfacing with Virtual Machines trough javascript. In order to accomondate the asynchronous and insecure nature of web technology a various solutions were developed. In this tutorial we are going to exlpain these solutions and some of the terms that you are going to see throughout this tutorial.
A session is almost equivalent to a Virtual Machine. However oppening a session doesn't mean that you start a Virtual Machine. We could say that a session is the description of a virtual machine and the channel to control it's instance.
In order to start or control a Virtual Machine instance you need to open a session that describes it first. Oppening a session either creates a new description or reuses a previous one. Keep this for now and we are going to use this later in the tutorial.
Now, let's say that Alice uses the CernVM WebAPI on the domain 'www.alicevms.com' to create a session called AliceVM
. A friend of her,s Bob, has another domain, 'www.bobvms.com', with permission to use CernVM WebAPI. Assuming that they can communicate with eachother, how do you ensure that only these two users can control the AliceVM
instance?
This problem is solved using a shared secret to lock each session. After a session is created it's not possible for anoyone else to open the same session unless (s)he knows that key.
In order to ensure that no malicious Virtual Machines are launched in the user's computer, each entity that uses CernVM WebAPI must be authorized in advanced. This authorization is implemented via a public key infrastructure. The developer creates an RSA key pair and submits the public key to the CernVM Group, along with the name of the domain where the extension will be used. After verification of the identity of the requestor and the domain, the key is registered in a public key database and grants access to CernVM WebAPI under the given domain name.
In order to validate the domain key, each request to open a VM session must be signed. A VMCP server takes care of signing such requests.
The VMCP endpoint (Virtual Machine Configuration Point) is a URL that provides signed information regarding the Virtual Machine to be launched. The only way to open a session is to point CernVM WebAPI to the VMCP URL.
The response is expected to be a JSON object with the information required, plus an RSA signature with the private key associated to the domain the plug-in is used.
For more information regarding the available configuration options have a look on the VMCP Reference.
It's importat to note that the domain key is refering to the domain where the extension is launched from and NOT where the VMCP endpoint is hosted at.
This means that if you are on www.mydomain.com
and you are fetching the VMCP information from http://vmcp.mydomain.com/machine/1442
you should get a private key for the domain www.mydomain.com
and NOT for the domain vmcp.mydomain.com
.