If I understood correctly what I've found searching around, a capability is "an unforgeable ticket, which when presented can be taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket" (1). So there is an authority that gives a capability to an object, which in turn can pass the capability to some other trusted object ("Capabilities can be delegated" and "Capabilities can be copied" (2)).

When you need to access something, you must pass a ticket that will be verified on the other side; in other words, invoking a method is not sufficient, you need the right ticket.

There is still something unclear to me: who will issue tickets? Will an object request a ticket or the object itself will be created with some tickets?

HTH, Valerio

1) http://www.cap-lore.com/CapTheory/ProtInf/
2) http://www.eros-os.org/essays/capintro.html

First off, REST and capability based security are separate issues. You can have either one without the other. I like REST, but I'll ignore it from now on and just talk about capabilities.

Let's use a hypothetical message board system to illustrate the differences in style between an access control list model and a capability based model. People can read messages, add new posts, administrators can edit them, etc.

In a traditional Access Control List security model you would have different users, each of which has different permissions, so you'll do things like this:

my $b = Board->fetch(board => "perl-examples");

my ($subject, $message) = $b->get_post(
    user => $u, post_id => 42
) or die "$u cannot get";

$b->new_post(
    user => $u, 
    subject => "hi", 
    message => "print 'hello world'"
) or die "$u cannot new";

$b->set_post(
    user => $u, 
    post_id => 42,
    subject => "42", 
    message => "is the answer"
) or die "$u cannot set";
[download]

You have a single user that has permission to do one or more operations.

With an capability model you ask for the capability to do something - and get given an object that will let you do the operation.

my $b = Board->fetch(board => "perl-examples");
my $get = $b->can_get or die "cannot get";
my $new = $b->can_new or die "cannot new";
my $set = $b->can_set or die "cannot set";

$get->(post_id = 42);
$new->(subject => 'hi', message => "print 'hello world'");
$set->(post_id => 42, subject => "42", message => "is the answer");
[download]

You have multiple capabilities each of which allows you to perform individual operations

Why do it like this? Because it gives you great advantages in the granuality and scope of your security model.

Let's do a hypothetical task with our board system - create-table-of-contents.

We want to have a message on the board that contains a list of all the subject lines of the posts on that board. To do this we need to:

• find-subjects (scan the posts for the subject lines)
• update-toc (update table of contents message)

With an ACL model you would have run our create-table-of-contents routine with a user who can both get and set messages.

The disadvantage of this model is that the bit of code that reads the subjects doesn't need the ability to write posts. Equally, the bit of code that needs to update the table-of-contents message does not need the ability to read posts.

If you make a mistake in your reading code (or a malicious user subverts it somehow) then you can make unwanted changes to the contents of your board.

With a capability based model you would only give find-subjects the "get" capability object. You would only give update-toc the "set" capability object. Even if an evil user subverted find-subjects they wouldn't be able to make changes to the board since it lacks the appropriate capability object.

Having this fine level of granuality makes tweaking your security model so much easier. For example, we might discover that our admin users wander off leaving themselves logged in - allowing nasty people to come use there account to change posts.

With our ACL model one option is to expire the user if there has been no activity in 10 minutes. Unfortunately, this annoys our admin users since they spend most of the time doing "normal user" things and don't like to find themselves logged out all of the time.

With our capability model we have finer control and we can expire the "set" capability object after ten minutes inactivity - leaving the users "normal" capabilities still in full affect.

There are lots of variations on this sort of thing. Without knowing more about the particular problem you are trying to address it's hard to say whether ACLs or a Capability model would be better for you - but hopefully this makes the concept easier to get a handle on ;-)

I forgot to mention - I'm using PostgreSQL for object persistance so it'd be nice to think of implementations that wouldn't be alien to it. But then this is a more general question so however it makes sense for you.

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;
[download]