Locomote.sh provides a flexible, extensible access control mechanism (ACM) which allows fine-grained access to the contents of a Locomote repository which can be controlled at the file level, or can even be configured to filter a file’s contents according to a user’s permissions.

Basic mechanism

Locomote’s ACM operates on the basis of group membership. A Locomote user - who may be authenticated or unauthenticated - receives a set of group memberships based on their identity. Each group may have a set of files associated with it, and membership of the group gives a user read access to that set of associated files.

The standard groups in Locomote are associated with the different filesets defined for a content repository, so for example, every user belongs to the ‘post’ group, which gives access to the set of files describing posts in the repository. Arbitrary groups can also be defined which don’t have a direct correlation with a fileset, but for these to be useful there should be a fileset processor which uses the group name to filter the files visible to a user. The fileset processor mechanism allows the ACM to control not just what files are visible to a user, but also allows the contents of individual files to be filtered by a user’s group membership.

Locomote is able to apply this fine level of access control whilst still maintaining efficient, progressive client updates as the data in a content repository is modified.

User authentication

By default, every user accessing a content repository is an anonymous, unauthenticated user, and Locomote allows full access to every file on the repository’s public branch which is assigned to a fileset. When access restrictions are required, individual repositories can be configured with a user authentication mechanism and additional fileset definitions which define access to restricted files.

Client authentication is performed using HTTP basic authentication. On the server, a content repository can be configured with user information by adding user names and hashed passwords to the repository manifest. This is suitable when access for only a small number of users is needed. When larger numbers are needed, Locomote’s authentication mechanism can be extended to interface with other systems providing authentication services, e.g. such as enterprise user directory systems.

Whatever authentication mechanism is used, it needs to define the authenticated user’s group membership, and this can be simply done by returning a list of group names each time a user is authenticated.

Agent derived groups

Locomote also derives some of a user’s group memberships from the user agent being used to access the repository, and this is done regardless of whether the user is authenticated or not. The user agent being referred to here is the tool - e.g. SDK or browser - being used by the user to interact with the Locomote server, and from which the server can glean information about what platform the user is using (e.g. iOS or Android), or what display characteristics the user’s device has etc. The group memberships assigned to the user this way are then used to control whether an app downloads images for iOS or Android, or for a high resolution or low resolution display, etc.