[cap-talk] Semantics : is this a capability system & am I using the
capibara at xs4all.nl
Tue Apr 12 06:50:56 EDT 2005
My previous post got no responses, maybe as I used a url to point at the
relevant info. For this reason I now try this second post.
I am working on a simple authorization system with tight cooperation
possibilities for incident response systems, and have been borrowing
many concepts form different ways of working with authorizations.
The only thing is that I combine and use these concept rather different.
Being afraid I may be misuse the naming, I have one important question:
'am I using the right semantics?'
Let me give a quick and simplified description of the system
I hope that describing it short does not make it to short on
relevant information needed for you to parse what I mean:
1 In TRACS, any operation that is to be authorized is seen as an 'event'
on a chain of 'stateful' objects, with the left most stateful being the
initiator, and the right most stateful being the target.
2 Each stateful and each event is a memeber of one or more 'objectgroup'.
3 A stateful has a state that references the active 'role' of the
4 A role has something I call a 'contextmatrix', that is a matrix of
'contexts' that are containers for rights (and lefts).
5 By its position in the chain, the stateful (for a single operation) has
two properties: a) the position of the stateful 'left' from the target,
and b) the position of the stateful 'right' from the initiator.
These two properties determine the relevant two 'contexts' for this
operation for the stateful within the 'contextmatrix' of its active
6 A context inside the context matrix is a container for what I call
'lr's, this stands for 'lefts' and rights. If an operation is directed
from an initiator to a target, the initiator needs a 'right' to perform
while the target needs an ACL like 'left' to be able to be used as the
subject of the operation.
7 An 'lr' is (dependent on its location in the contextmatrix) either
a left or a right. It combines a reference to either a stateful or an
objectgroup with a reference to either an event or (event)objectgroup.
The scope of an lr may be limited by two ranges, a range that determines
the location in the chain the target of the lr should be at, and a
second range that determines the size of the chain that the lr is valid
8 For an operation to be authorized, for all possible links between two
nodes in the chain there has to be both a left and a right to enable
the operation to become authorized. This means that a total of N*(N-1)
lr's is required to autorize a single operation. This means these
operations are expensive, thus we define the folowing:
9 The system requesting authorization for the action will mostly be one of the
first few statefuls. If authorization for an event on a chain of
statefuls is granted, than the tracs system will return a 'capability'
ticket to the requester. This capability will remain valid as untill it
explicitly expires (as defined in the capability) or until the state
of one of the stateful object changes. The TRACS system will require
less efford to 'validate' a capability than to re determine it.
10 A capability may be forwarded to and used by statefuls further down
the line. Thus in a client/proxy/server, the client may request the
capability and forward it to the proxy and the server, who will than
only have to asc TRACS to validate the capability.
Based on this setup, I have a few important questions:
* Am I using the right semantics for the concepts that I use?
* Is this or is this not a capability system, and am I using the
term capability for the right thingy (the authorization ticket).
I hope someone here will be able to help me to get the semantics of my
design in order.
Rob J Meijer
More information about the cap-talk