Security Model

Copyright: 2009 University of Southampton, IT Innovation Centre


The prototype uses an object-capability security model for access control, both between services and between objects within services. Communications are encrypted using transport layer security and servers are authenticated when establishing a connection.

Individual objects within the system have only the limited authority needed to perform their functions. A compromised object cannot give an attacker more authority than the object itself has.

However, as an experimental prototype, some objects may currently expose more operations than they should. In other words, once you have access to an object in the system it is possible that you can gain access to other objects to which you should not have access.


A process contains one or more vats. A vat has an identity (key-pair) and contains objects. A capability is a transferable, unforgeable reference to an object.


Access control is based on capabilities. A capability is a reference to an object, and grants the holder permission to invoke any method on that object. Access is not based on identity (i.e. who is accessing the object).

When serialised, a capability looks like this:


The parts are (from left to right):

  • The scheme identifier, captp (the Capability Transport Protocol).
  • The fingerprint of the hosting vat's public key.
  • The IP address and port of the hosting vat.
  • The Swiss number of the object.

A Swiss number is a long unguessable identifier, generated by a secure pseudo-random number generator. Knowledge of this number is necessary and sufficient to have access to the object.

A capability URL therefore allows a client to connect to a server securely. The client is sure it is connected to the right server because the server's public key hashes to the fingerprint. If the server presents a public key it doesn't own, it won't be able to decrypt the messages the client sends.

Care must be taken when transmitting capability URLs (e.g. by email), since anyone who knows the URL can use the object. Emails should therefore be encrypted. It may be wise to store capabilities on an encrypted file-system.

For information about object capabilities (and why they are often preferable to identity-based systems), see:


To benefit from this design, each object should have access only to those objects it needs to perform its function. This diagram shows some of the objects involved when running a batch processing job:


Object capability diagram for a batch job

An arrow from A to B indicates that A has a reference to B, and can invoke any of B's methods.

A user (user_1) has a capability for the "job" object. The job object has access to the job's inputs and outputs and to the actual application instance.

It offers its access to the input freely to the user, but gives read-only access to the output. To the application, it gives read-only access to the input but write access to the output.

The owner of the job (user_1), has given user_2 access to the output.

If an attacker (e.g. user_2) could somehow take full control of the read-only output object (e.g. due to a security flaw in this object), they would gain the ability to write data to the output before the application did, but nothing else. For example, no bug in the read-only output's code can give user_2 access to the job's input, because the output object doesn't have access to it itself.

Identity-based Access Control

While capabilities provide an efficient and secure access control mechanism for computer programs, it is less clear whether they are useful for managing access by humans. It is therefore expected that Ting will support both mechanisms:

  • A human user will use their identity (e.g. an X.509 certificate) to query a registry of resources to which they have access. This is controlled using an access control list.
  • The human will retrieve capabilities to the resources from the registry. They will give these capabilities to the programs they run, as necessary. The programs will invoke the objects using these capabilities, and not by using the user's identity.

This is the same model used in Unix, for example, where a user opens a file using their identity (as a logged-in Unix user), matched against the file's access control rules. Once opened, the result is a file descriptor, which is a capability. The capability can be transferred to another process, running as a different user who would not be able to open the file.


To delegate access to an object to someone else, you create an Authorisation. This is a server-side proxy that forwards messages to the original object. You out give a capability to the Authorisation, not to the underlying object. This allows you to manage and revoke access as needed.

Each Authorisation gives a set of roles that it grants. Each role maps to a set of operations (methods). An Authorisation will only forward a message if the method name is allowed by one of the roles.

For example, the data stager type defines the roles "reader" and "writer". An Authorisation granting the "reader" role forwards "get", "getStatus", etc. methods, while one with the "writer" role forwards "put", "copyFrom", etc.

Open Issues