Access control

From Friend2Friend Wiki

Basic Access Control in F2F is a deliberately simple affair. Permission to carry out a request rests on 2 things: its URI, and the effective uid at the point that the request is made. Part of the module compilation process creates a table of the URIs available from each soft node, and an access control entry for each service, of type <f2f:acl>, which is either a blacklist or a whitelist, according to its definition file.

Contents 1 uid 2 Controlling Access 3 To Do 3.1 Data Level Access Control 3.2 User Identity 3.3 Further Ideas 4 References

uid

uid is an unsignedLong, used within the soft-system as a simpler alternative to the public key of the original request. It is swapped for the key by a pair of filters at the soft root node. Since they also have public keys, modules has their own uids, just like system users. Privileged services are so called because they operate with the uid of their creator, not their invoker, for some or all iterations. These are often used in conjunction to forbidding any other uid's access to the datastore manipulation core services (xml*, bag-*). This allows a module to ensure only its own scripts accessing datastores.

Controlling Access

Access may be controlled through use of the access-set and access-get core services at the node concerned. This layer is intended to work as a foundation for subsequent dedicated access-control modules, of which the only one so far is identity, which groups together sets of uids into a single identity group.

To Do

The above Access Control measures apply at the level of the request, which is a starting point, but will benefit from augmentation.

Data Level Access Control

Access control on individual data items could be implemented in a variety of ways:

Method	Description	+	-
Filters	The bag-* services are simple enough that filters could	Simple	Loses the XML structure of relationships between data
Multiple Datastores	Use the node-datastore-add service to have as many daastores as users, and give them free rein over their own data, perhaps read access over their friends.	Simple	Loses the XML structure of relationships between data
Intersperse ACL in the XML	Use ProcessingInstructions to mark up permissions. Filters could remove any forbidden data.	Relatively simple - the XML will still behave as expected, and we don't use PIs yet anyway Easily human readable - all the data in one place	Annoying to lose full generality of XML; logical problems if we have databases of databases Complex interaaction with filters if the data is accessed using XPath?
Parallel Metadatatores	Maintain corresponding XML of metadata to record the permissions of the XML datastore	Pretty simple. Division of data from metadata. No limit to generality of stored information; could be coded, e.g. by wrapping bag-* services and then forgotten about	Slow; multiple file accesses Might get out of sync/corrupted = dataloss or security issue

User Identity

One person may use multiple keys, for example, if they use multiple systems. The identity module translates the different uids into an <identity:igroup>, indended to be a single individual or organisation.

Further Ideas

A useful tool for evaluating access control decisions would be to automate a ring round, e.g. to contact friends servers and ask for their opinions about someones trustworthiness, then use the answers to make an decision. The would be the suitable goal for a module, which could intercept such traffic with a filter.

References

• FF10 - Access Control